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ABSTRACT 


This  thesis  introduces  the  concept  of  an  Intranet,  chronicles  the  efforts  required  to 
create  and  deliver  an  Intranet,  and  provides  a  discussion  of  advantages  and  disadvantages 
of  using  an  Intranet.  It  demonstrates  that  an  Intranet  can  be  a  useful  mechanism  to  solve 
problems  related  to  information  control  and  distribution  for  the  reserve  component  of  the 
40*  Infantry  Division  (Mechanized). 

The  thesis  contains  a  detailed  description  of  the  rapid  prototyping  process  model, 
as  well  as  the  modifications  required  to  adapt  the  process  for  Intranet  development. 
Further,  it  describes  the  gathering  of  system  requirements  using  the  results  of  several 
structured  walk-throughs.  It  also  describes,  in  detail,  the  development  efforts  to  address 
each  of  the  requirements  identified. 

The  prototype  developed  as  part  of  this  thesis  demonstrates  several  key  aspects  of 
Intranet  development  and  deployment.  For  example,  it  incorporates  webpage 
development  using  Commercial-Off-The-Shelf  products  common  to  the  division,  and  the 
development  of  interactive  functions  with  spreadsheet  and  database  programs.  This  thesis 
also  addresses  issues  such  as  security  and  content  control  which  are  crucial  for  Intranet 
deployment. 
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L  INTRODUCTION 


A.  BACKGROUND 

In  October  of  1996,  the  40*  Infantry  Division  (Mechanized)  lost  its  ability  to 
transmit  data  electronically  when  the  state’s  primary  electronic  mail  server  was  shut 
down  in  Rocklin,  California.  The  reason  for  the  server  shutdown  was  based  on  the 
determination  that  the  cumulative  service  being  provided  by  the  division’s  automation 
system  (known  as  the  Reserve  Component  Automation  System  (RCAS))  was 
substandard.  The  decision  was  made  to  pull  the  plug  on  the  e-mail  life  support  system 
and  shut  down  the  server.  Given  this  significant  readiness  impact,  within  days,  the 
division’s  Chief  of  Staff  directed  the  division’s  organic  signal  unit,  the  240*  Signal 
Battalion  to  develop  and  provide  the  division  with  a  means  to  commumcate 
electronically.  Through  state  funding,  the  division  procured  the  hardware,  software,  and 
connectivity  necessary  to  establish  itself  as  an  Internet  Service  Provider  (ISP). 

Our  mission,  given  to  us  by  our  sponsor,  LTC  Rod  Barham,  commander  of  the 
240*  Signal  Battalion,  was  to  develop  an  Intranet  prototype  which,  first,  because  of  the 
short  time  constraints,  could  be  developed  quickly  and  second,  reflected  the  requirements 
and  desires  of  the  users  to  the  extent  possible,  given  the  time  constraints. 

We  met  with  our  sponsor  on  19  December,  1996  (Appendix  A  —  TRIP  REPORT 
1)  to  further  define  the  scope  of  our  mission  and  to  gather  initial  requirements.  Following 
our  initial  development  effort,  we  met  with  our  cxostomer  to  demonstrate  our  initial 
prototype  efforts  and  to  further  define  and  refine  user  requirements  (Appendix  B  -  TRIP 
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REPORT  2).  We  delivered  an  operational  prototype  to  our  sponsor  on  2  May,  1997 
which,  because  of  the  need,  was  put  on-line  and  made  available  to  users  that  afternoon. 

The  goal  of  this  thesis  was  to  work  with  a  military  organization  and  focus  on 
readiness  improvement  through  the  development  of  an  Intranet  prototype. 

B.  WHAT  IS  AN  INTRANET? 

An  Intranet  is  a  combination  of  a  Local  Area  Network  (LAN),  Wide  Area 
Network  (WAN),  and  internet  technologies  (i.e.,  http  and  IP  protocols.  World  Wide  Web 
(WWW)  browsers  and  servers,  etc.)  through  which  members  of  an  organization,  located 
anywhere  in  the  world,  can  connect  people  and  information  electronically  in  order  to 
more  efficiently  and  effectively  conduct  business.  The  internal  net  or  Intranet  can  be 
restricted  to  those  authorized  access  by  the  organization. 

C.  CONTENTS 

This  thesis  contains  seven  chapters  and  two  appendixes. 

1.  Chapter  I  Introduction 

This  is  the  foundation  chapter  and  gives  a  brief  backgroimd  followed  by  a  thesis 
content  section. 

2.  Chapter  II  Intranet 

This  chapter  discusses  the  advantages  of  Intranet  use  followed  by  a  discussion  on 
the  client/server  model  of  computing.  Hardware  and  software  requirements  for 
establishing  an  Intranet  are  also  covered.  The  final  section  in  Chapter  II  is  a  discussion 
about  the  information  creation  and  consumption  model. 
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3.  Chapter  III  The  Customer 

Chapter  III  discusses  the  history,  organization,  structure,  and  mission  of  the  40* 
Infantry  Division  (Mechanized).  The  Reserve  Component  Automation  System  is  the 
U.S.  Army  National  Guard  and  Reserve  office  automation  system.  The  RCAS  system, 
which  was  fielded  in  its  entirety  in  California  (the  first  state  to  be  fielded),  went  through  a 
major  program  redevelopment  following  numerous  cries  of  discontent  firom  its  user  base. 
The  fielding  of  the  “old”  RCAS  system  was  halted  while  the  program  was  reviewed  and  a 
“new”  RCAS  system  emerged  as  a  result.  Federal  funding  for  “new”  RCAS  components 
is  expected  in  second  quarter  of  FY98.  The  state  and  the  division  are  working  interim 
solutions  (i.e..  Intranet  prototype)  in  order  to  provide  the  iisers  with  high  quality 
electronic/digital  service  imtil  the  federal  funding  for  the  new  system  arrives. 

4.  Chapter  IV  The  Prototyping  Process 

The  methodology  used  for  the  development  of  the  Intranet  was  the  prototype 
model.  This  chapter  initially  contrasts  the  traditional  waterfall  model  with  the  prototype 
model  followed  by  a  section  discussing  the  benefits  and  drawbacks  of  using  the  prototype 
model.  The  scope  of  this  thesis  is  also  covered  in  this  chapter.  The  Division’s  current 
information  operations  are  discussed  and,  finally,  the  adaptation  of  the  prototype  model 
to  the  development  of  a  military  Intranet  is  covered. 

5.  Chapter  V  Identification  of  Basic  Requirements 

This  chapter  discusses  the  methodology  used  to  gather  requirements.  Also 
presented  is  a  discussion  on  the  requirements  gleaned  from  meetings  with  the  sponsor. 
These  requirements  were  used  in  developing  the  prototype. 
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6.  Chapter  VI  The  Prototype 

This  chapter  covers  the  actual  Intranet  prototype.  Numerous  screen  shots  are 
provided  to  give  the  reader  the  “look  and  feel”  of  the  developed  prototype.  The 
discussion  of  the  prototype  is  related  to  the  sponsor’s  requirements,  which  are  presented 
in  Chapter  V. 

7.  Chapter  VII  Recommendations  for  Intranet  Operation 

It  is  imperative  that  the  division  establishes  policy  as  soon  as  possible  regarding 
the  further  development,  implementation,  and  use  of  the  Intranet.  This  chapter  discusses 
Intranet  policy  and  recommendations  concerning  policy  areas  which  should  be  included 
in  a  division  Intranet  policy.  This  chapter  also  contains  a  section  on  Intranet  lessons 
learned.  These  lessons  learned  are  a  compilation  of  ideas  developed  through  the 
numerous  readings  done  in  this  area.  This  section  lists  eight  recommended  steps  the 
division  should  follow  in  order  to  insure  success. 
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II.  INTRANET 


A.  INTRODUCTION 

Chapter  I  provided  a  definition  of  an  Intranet.  This  chapter  will  present  some  of 
the  advantages  of  Intranet  use.  This  will  be  followed  by  a  review  of  Intranet 
technologies.  This  includes  a  brief  mention  of  the  client/server  model  which  is  the  heart 
of  the  web-based  functionality  of  an  Intranet.  Hardware  and  software  requirements  for 
setting  up  an  Intranet  are  also  covered  in  this  chapter.  Finally,  a  section  is  presented  on 
information  creation  and  consumption. 

B.  ADVANTAGES  OF  INTRANET  USE 

A  recent  study  by  Network  World  found  that  eighty-nine  percent  of  organizations 

sampled  already  have  implemented  or  will  implement  an  Intranet  strategy  in  the  next 
twelve  months  [1.2].  The  large  percentage  of  organizations  that  have  implemented  or 
planning  to  implement  Intranets  have  been  attracted  by  the  numerous  benefits  provided 
by  Intranets.  Some  of  these  benefits  include: 

1.  Simplified  Information  Access 

With  the  use  of  an  organizational  web  server  and  a  client  web  browser,  an 
unlimited  amount  of  static  and  dynamic  information  can  be  accessible  to  the  user. 
Organizational  policies,  procedures,  regulations,  and  databases  are  just  a  few  examples  of 
the  types  of  information  that  can  be  accessed  on  an  Intranet. 

2.  Enhancement  of  Communication  and  Collaboration 
Information  flow  improves  with  the  capabilities  of  conducting  on-line 

collaboration  through  real-time  “whiteboarding”  and  near  real-time  messaging  through 
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electronic  mail.  Multipurpose  Internet  Mail  Extensions  (MIME)  is  a  mechanism  that 
allows  users  to  attach  application  specific  files  to  electronic  mail  which  are  then 
recovered  on  the  receiving  end  for  review,  update,  or  further  processing.  Applications 
like  Microsoft’s  Netmeeting  allow  users  to  conduct  on-line  chat  room  discussions  and 
collective  document  preparation.  Information  dissemination  is  simplified  for 
organizational  command  and  control  elements. 

3.  Productivity  Enhancement 

Combining  the  capabilities  an  Intranet  set  of  tools  provides  postures  an 
organization  to  become  a  more  productive  entity.  Processing  and  accessing  information 
by  electronic  means  simplifies  the  communication  process.  Electronic  mail  allows  users 
to  respond  on  their  time  rather  than  having  to  respond  on  demand  to  an  interuptive  phone 
call.  Collaborative  tools  allow  groups  who  are  geographically  dispersed  to  brainstorm 
and  come  to  consensus  on  team  issues.  Web  pages  allow  department  information 
providers  the  ability  to  quickly  disseminate  information.  On  the  user  side,  the  Intranet 
allows  the  user  the  flexibility  to  “pull”  information,  based  on  a  need  or  desire  to  know. 
Examples  such  as  these  illustrate  a  work  environment  that  allows  individuals  and  teams 
to  focus  on  their  work  tasks  by  providing  a  system  that  puts  information  literally  at  the 
fingertips  of  the  organization. 

4.  Decision  Support 

One  of  the  major  strengths  of  an  Intranet  as  a  mechanism  for  decision  support  is 
that  it  facilitates  access  to  distributed  information  and  distributed  access  to  desired 
information.  This  information  can  be  in  the  form  of  data  and  models  and  can  be  obtained 
from  different  sources  in  a  variety  of  formats  and  media,  locally  or  remotely.  The 
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Intranet  provides  a  user-fnendly  mechanism  for  rapid  access  to  information  required  for 
decision-making  by  facilitating  the  links  between  data,  models  and  users.  [2.2] 

5.  Affordability 

One  of  the  reasons  Intranets  are  so  appealing  is  the  fact  that  web  technology  is 
inexpensive.  The  basic  system  configuration  consists  of  a  server  hardware 
platform/operating  system  and  WWW  server  software.  On  the  user  side,  employees  only 
need  an  inexpensive  browser  to  navigate  the  information.  A  study  conducted  by  U.S. 
Computer,  and  funded  by  Sun’s  Internet  Commerce  Group,  indicates  that  web 
technologies  can  reduce  internal  corporate  networking  costs  by  as  much  as  $1 1  million 
over  four  years  for  a  large  network  [2.3]. 

6.  Ease-of-Use 

Another  major  driving  force  behind  the  growth  of  Intranets  is  that  the  technology 
is  intuitive  and  easy  to  use.  Little  training  is  needed  before  employees  are  “up  and 
running”  on  the  Intranet.  Using  their  browsers,  employees  use  hypertext  links  to  search 
for  and  access  text,  graphics,  audio,  or  video.  At  a  very  basic  level,  this  means 
organizations  can  hold  down  printing  and  distribution  costs  for  documents  that  are  now 
produced  on  paper,  such  as  organization  policy  letters  and  standing  operating  procedures. 

C.  INTRANET  TECHNOLOGIES 

1.  The  Client/Server  Model 

The  WWW  and  Intemet/Intranet  technologies  are  based  on  the  client/server 
model  shown  in  Figure  2.1.  To  truly  understand  how  an  Intranet  operates,  it  is  important 
to  imderstand  the  concept  of  client/server  computing.  The  client/server  model  is  a  form 
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of  distributed  computing  where  one  program  (the  client)  commimicates  with  another 
program  (the  server)  for  the  pxupose  of  exchanging  information  [2.4]. 


Web  server  Web  client  (browser) 


Figure  2.1.  Client  Server  Dialog  [2.5] 


The  WWW  uses  a  distributed  client/server  architecture  built  aroimd  a  message 
based  on  resource  servers  and  client  browsers  as  illustrated  in  Figure  2.1 .  Although  it  is, 
for  the  most  part,  transparent  to  the  end  users,  browsing  is  a  two-step  process  of 
downloading  data  from  the  server  and  then  acting  on  it.  This  provides  the  opportunity  to 
act  on  data  with  a  browser  or  laimch  a  new  application  for  specific  data  types  and, 
consequently,  the  behavior  is  easily  extended. 

Key  WWW  specifications  include  the  H5q)ertext  Markup  Language  (HTML), 
Uniform  Resource  Locators  (URLs),  Multipurpose  Internet  Mail  Extension  (MIME)  and 
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the  HyperText  Transfer  Protocol  (HTTP)  [2.6].  These  specifications  are  discussed 
below: 

•  Hypertext  Markup  Language  (HTML)  -  HTML  is  used  when 
publishing  a  document  that  is  to  be  displayed  through  the  WWW. 

HTML  is  a  set  of  simple  syntax  commands  that  describes  how  a 
document  is  structured.  This  language  allows  the  user  to  define  the 
parts  of  a  document,  but  not  the  formatting,  so  that  the  browser  used 
for  reading  the  document  can  format  it  best  to  suit  the  user's  display. 

•  Uniform  Resource  Locators  (URLs)  -  a  URL  is  a  complete  description 
of  an  item,  containing  the  location  of  the  item  you  want  to  retrieve.  A 
typical  URL  looks  like  this:  http://jupiter.as.nps.navy.mil/40thdiv .  The  first 
item  in  the  URL  (the  portion  that  ends  with  a  colon)  is  the  protocol 
used  to  retrieve  the  item.  For  this  URL  the  protocol  is  HyperText 
Transfer  Protocol.  The  two  forward  slashes  that  follow  indicate  that 
what  follows  is  a  valid  host  address.  It  can  either  be  the  text  as  shown 
or  the  actual  corresponding  IP  address  of  the  site.  40*div,  in  this  case, 
is  the  default  homepage  for  the  web  site  titled  40thdiv. 

•  Multipurpose  Internet  Mail  Extension  (MIME)  -  MIME  is  an 
extension  to  the  existing  Simple  Mail  Transport  Protocol  (SMTP) 
standards  that  offer  a  standardized  way  to  represent  and  encode  a  wide 
variety  of  media  types,  including  textual  data  in  non- ASCII  character 
sets,  for  transmission  via  internet  mail  [2.7]. 

•  HyperText  Transfer  Protocol  (HTTP)  -  After  it  was  decided  to  use 
hypertext  as  the  standard  format  for  WWW  documents,  a  protocol  that 
allowed  these  hypertext  documents  to  be  retrieved  quickly  was 
developed.  This  protocol  is  HTTP.  HTTP  is  a  simple  communication 
protocol  that  allows  the  document  it  is  retrieving  to  retain  hyperlinks 
to  other  documents  during  download. 

Using  Figures  2.1  and  2.2,  a  scenario  can  be  presented  to  illustrate  a  typical 
process  in  an  Intranet  environment:  user  with  access  to  the  local  area  network  via  a  direct 
connection  or  a  dial-in  capability  has  a  web  browser  residing  on  his/her  client  machine. 
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Browser 


Figure  2.2.  Browser/Server  Communication  [2.8] 

The  browser  reads  a  document  written  in  HTML  and  displays  it  for  the  user, 
interpreting  all  the  markup  codes.  When  the  user  clicks  on  a  hyperlink  in  an  HTML 
document,  the  browser  uses  the  HyperText  Transfer  Protocol  (HTTP)  to  send  a  network 
request  to  a  web  server  to  access  the  new  document  or  service  specified  by  the  hyperlink 
(i.e.,  service  using  server  based  programs).  The  client’s  request  is  handled  in  one  of  two 
ways.  If  the  request  is  for  a  document  or  data,  the  response  involves  the  delivery  of  the 
docximent  or  data  to  the  client  browser. 

A  second  situation  is  if  the  user  is  requesting  some  type  of  service  from  the  server 
(i.e.,  post  data  to  a  database,  query  database,  server  side  processing,  etc.).  In  order  to 
access  server  programs  and  invoke  them  from  a  web  client,  the  server  uses  a  Common 
Gateway  Interface.  The  function  of  the  CGI  is  to  interpret  service  requests  from  the 
server  to  server  based  programs.  The  Open  DataBase  Connectivity  standard  is  a  form  of 
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CGI  developed  by  Microsoft  to  allow  browsers  and  servers  the  ability  to  interact 
remotely  with  server  based  database  programs.  Once  the  server  services  a  request-based 
program,  a  response  is  sent  back  to  the  user’s  browser  (i.e.,  query  results).  When  the 
response  comes  back  to  the  user’s  browser,  the  HTML  interpreter  displays  the  requested 
document.  The  displayed  document  contains  hyperlinks  with  underlying  URL  locations 
for  other  web  server  based  documents  and  data. 

Browsers  can  be  configured  to  laimch  executable  files  the  moment  a  server 
response  is  received.  For  instance,  a  request  is  made  for  an  administrative  form  that 
resides  on  the  server.  The  moment  the  file  is  returned  to  the  browser,  the  browser 
invokes  the  executable  command  for  the  application  residing  on  the  client’s  machine  (i.e., 
administrative  form  preparation  program)  and  launches  the  application.  After  completing 
the  form,  the  user  can  immediately  launch  a  mailer  (both  Internet  Explorer  and  Netscape 
have  mail  clients  that  reside  in  the  browser  environment),  attach  the  form  as  a  MIME  and 
send  it  to  other  Intranet  users  for  action  or  additional  processing. 

D.  HARDWARE  AND  SOFTWARE  REQUIREMENTS 

An  Intranet  can  be  tailored  to  the  organization’ s  information  requirements.  The 
heart  of  an  Intranet  is  the  host  or  server.  As  mentioned  previously,  members  of  the 
organization  will  have  access  to  the  Intranet  through  the  Local  Area  Network  (LAN)  or 
through  other  means  such  as  dial-in  access  via  a  modem. 

Requirements: 

•  server  computer  on  LAN  with  appropriate  web  server  software  such  as 

Microsoft’s  Internet  Information  Server  (IIS).  Once  the  scope  of  the  Intranet 
is  defined,  the  server  computer  should  have  sufficient  CPU,  RAM,  and  Disk 
Storage  resources  to  handle  the  expected  load  of  “requests”  from  numerous 
client  browsers  accessing  the  server  simultaneously. 
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•  authoring  software  such  as  Microsoft  Frontpage  to  create  and  update  site 
content 

•  browsing  (client)  software  such  as  Netscape  Navigator  and  Microsoft’s 
Internet  Explorer  for  all  users 

•  other  server  software,  such  as  mail  server  software,  which  will  permit  the  use 
of  electronic  mail  across  the  network 

E.  INFORMATION  CREATION  AND  CONSUMPTION 

The  previous  section  implies  that,  from  a  purely  hardware  and  software 

perspective,  putting  together  an  operational  Intranet  is  not  a  difiBcult  task.  The  difficulty 

resides  in  administering  the  Intranet  so  that  it  provides  relevant,  up  to  date  and  useful 

information  to  users.  Chapter  VIII  covers  Intranet  operations  and  looks  specifically  at 

recommendations  for  Intranet  and  content  control.  Ultimately  there  will  be  a  need  to 

decentralize  the  process  of  Intranet  control  (i.e..  Divisions  delegate  brigade  web 

management  to  brigades,  brigades  to  battalions,  etc.)  This,  of  course,  only  occurs  after 

adequate  training  in  web  publication,  content  standards,  etc.  Figure  2.3  presents  an 

information  development  and  consumption  cycle  [2.9]  that  is  prevalent  in  an  Intranet 

environment.  This  model  assumes  a  decentralized  posture  within  the  organization. 
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Figure  2.3.  Information  Production  and  Consumption  Cycle  [2.9] 


A  typical  member  of  an  organi2ation  operates  in  the  context  of  an  information 
creation  and  consumption  process.  His/her  primary  product  is  new  information  in  the 
form  of  memorandums,  budgets,  proposals,  analysis,  presentations,  work  requests/orders, 
etc.  Each  of  these  “raw”  forms  of  information  requires  some  action  on  the  part  of  the 
information  recipient.  This  action  may  be  some  combination  of  content  creation, 
analysis,  data  access,  collaboration,  and  publishing  [2.9],  which  contributes  to  the  overall 
knowledge  base  of  the  organization. 

The  first  step  in  this  iterative  process  is  to  gather  content  worthy  of  further 
analysis  and,  ultimately,  to  publish  it  on  the  organization’s  Intranet.  An  individiial 
identified  to  be  the  responsible  person  (held  accountable  for  web-publishing  and  content) 
for  each  entity  (i.e.,  division  webmaster,  brigade  webmaster,  etc.)  will  gather  information 
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from  many  sources.  As  information  is  collected  and  analyzed,  the  webmaster  begins  to 
create  new  content  using  familiar  publishing  tools  like  Microsoft’s  FrontPage.  In  some 
situations,  content  creation  will  be  a  collaborative  effort,  where  team  members  work 
together  to  come  up  with  content.  Once  the  content  is  published,  the  information  is 
made  available  to  others  on  the  Intranet,  which  drives  them  into  the  creation  and 
consumption  cycle. 

The  tasks  within  the  creation  and  consumption  model  can  be  further  broken  down 
and  discussed: 

1.  Content  creation 

Some  documents,  by  their  nature,  require  frequent  revisions,  where  others  will 
only  have  to  be  updated  periodically.  Examples  of  documents  which  will  require 
frequent  updating  include:  training  schedules,  commander’s  guidance,  staff  notes, 
operation  orders,  intelligence  summaries,  etc.  Documents  which  will  only  be  updated 
periodically  include:  policy  letters,  standing  operating  procedures  (SOPs),  soldier 
packing  lists,  inspection  checklists,  etc.  The  dynamic  characteristics  of  any  organization 
cause  constant  change  in  current  information.  In  order  to  maintain  relevant,  meaningful, 
and  up-to-date  information,  the  webmaster  at  each  entity  level  has  to  keep  a  pulse  on 
what  information  is  being  provided  to  its  subscribers.  With  the  need  to  change  content 
often,  it  is  imperative  that  the  webmaster  be  provided  with  the  fiiendliest  publishing  tools 
available. 

2.  Analysis  and  Data  Access 

Office  application  suites  today  allow  the  user  to  save  text  documents, 
spreadsheets,  and  presentations  in  HTML  format.  Databases  can  be  tied  to  web  servers 


14 


via  common  gateways  such  as  Microsoft’s  Open  Database  Connectivity  Standard 
(ODBC).  These  functions  allow  Intranet  users  to  easily  access  and  analyze  budgets, 
proposals,  presentations,  etc.  The  ability  to  access  database  records  gives  authorized 
users  the  capability  to  remotely  update  those  records  and  conduct  analysis  on  existing 
records  through  queries.  The  ability  to  access  pertinent  information  quickly  allows  the 
user  to  conduct  analysis  more  quickly  and  thoroughly.  Providing  immediate  access  to 
relevant  documents  drastically  reduces  the  user’s  decision  cycle. 

3.  Collaboration 

Organizational  documents  often  have  many  authors  who  work  together  in  order  to 
produce  a  collective  product.  The  Intranet  environment  allows  users  to  review,  conunent 
on,  and  update  working  documents  before  final  versions  are  published. 

4.  Publishing 

One  of  the  greatest  benefits  of  having  an  Intranet  is  the  ability  to  quickly 
disseminate  information.  Once  created,  there  is  an  enormous  amount  of  information  that 
needs  to  be  shared  widely  within  an  organization,  such  as  operations  orders,  policies, 
procedures,  scheduling,  and  budgeting  information.  Current  application  publishing  tools 
make  converting  this  kind  of  information  into  HTML  documents  and  posting  them  on  an 
Intranet  a  very  simple  process. 

F.  CONCLUSION 

This  chapter  has  covered  a  broad  range  of  Intranet  related  topics  including  the 
benefits  provided  by  an  Intranet,  the  client/server  Intranet  architecture,  hardware  and 
software  requirements  necessary  to  implement  the  Intranet  and,  finally,  a  view  of  how  an 
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organization  develops  and  consumes  information.  The  following  chapter  focuses  on  the 
customer,  the  40*  Infantry  Division  (Mechanized). 
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in.  THE  CUSTOMER 


A.  INTRODUCTION 

As  mentioned  previously,  a  large  part  of  the  motivation  for  this  research  was  to 
develop  a  product  that  would  improve  the  readiness  of  a  military  organization.  Also 
mentioned  earlier  was  the  fact  that  a  search  for  a  military  customer  was  conducted 
immediately.  The  search  included  those  organizations  that  had  an  existing  technical 
architecture,  which  could  support  the  implementation  of  an  Intranet. 

This  chapter  focuses  on  the  customer,  the  40*  Infantry  Division  (Mechanized)  of 
the  California  National  Guard.  A  brief  history  of  the  Division  is  provided,  followed  by  a 
look  at  the  Division’s  organization,  structure  and  mission.  The  Reserve  Component 
Automation  System  (RCAS)  is  the  administrative  system  for  Army  National  Guard  and 
Reserve.  It  is  a  Wide  Area  Network  (WAN)  that  is  a  worldwide  system  proposed  to 
provide  interconnectivity  for  all  guard  and  reserve  units.  RCAS  is  a  multi-billion  dollar 
information  systems  acquisition  program,  which,  until  fielded  in  California,  leaves  a  void 
in  the  Division’s  ability  to  conduct  digital  information  sharing.  In  this  chapter,  the  RCAS 
program  is  addressed  first  followed  by  a  discussion  of  the  40*  Division  s  problem  of 
degraded  information  operations.  Finally,  a  discussion  the  proposed  solution,  of  which 
the  development  of  a  division  Intranet  is  a  major  part. 

B.  BACKGROUND 

1.  History 
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The  40*  Division  was  organized  at  Camp  Kearney,  near  San  Diego,  California,  on 
25  August  1917,  and  was  composed  of  National  Guard  organizations  of  the  states  of 
Arizona,  California,  Colorado,  Nevada,  New  Mexico,  and  Utah. 

The  division  fought  with  distinction  in  World  War  I,  World  War  II,  and  the 
Korean  War.  The  Division  has  four  recipients  of  The  Medal  of  Honor,  which  is  our 
coimtry’s  highest  award  for  bravery.  In  addition  to  the  division’s  gallant  federal  service, 
the  “Citizen-Soldiers”  of  the  40*  Infantry  Division  have  responded  to  countless  state 
emergencies,  providing  service  to  the  state  of  California.  Some  of  the  state  emergencies 
where  the  Division  distinguished  itself  include  the  Folsom  Prison  riots  (November, 

1927),  Long  Beach  earthquake  (March,  1933),  Sacramento  floods  (December,  1950), 
“Watts  Riot”  (August,  1965),  Los  Angeles  Civil  Disturbance  (1992)  and  the  Northridge 
Earthquake  (January,  1994). 

2.  Organization 

The  40*  Infantry  (Sunburst)  Division  is  headquartered  at  Los  Alamitos, 

California.  Figure  3.1  is  a  hierarchical  depiction  of  the  40*’ s  organization.  The  Division 
follows  what  is  known  as  the  active  Army’s  J-series  Table  of  Organizational  Equipment 
(TOE).  A  TOE  gives  like  units  the  same  authorization  for  persoimel  and  equipment.  The 
division  is  depicted  at  the  top  with  an  XX  (indicates  a  division  size  element)  symbol 
above  the  symbol  for  a  mechanized  infantry  unit.  The  division  consists  of  three 
maneuver  brigades  (each  with  three  battalion  size  elements),  an  aviation  brigade 
(consisting  of  four  aviation  battalions  and  one  air  cavalry  squadron),  an  artillery  brigade 
(with  three  battalion  and  two  company  sized  elements),  an  engineer  brigade  (consisting 
of  three  battalions),  and  a  division  support  brigade  (with  one  main  support  battalion  and 
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three  forward  support  battalions).  Also  organic  to  the  division  are  an  air  defense 
battalion,  a  signal  battalion,  a  military  intelligence  battalion,  a  Military  Police  (MP) 


XX 


9 


company,  a  chemical  company,  a  long-range  surveillance  company,  and  the  division 
band. 

3.  Structure 

Like  most  military  organizations,  the  mechanized  infantry  division  is 
hierarchically  structured.  Each  battalion  through  division  size  element  (entity)  has  a  staff 
of  primary  officers  who  assist  the  commander  in  planning,  coordinating,  preparing,  and 
executing  operations  within  and  outside  the  division.  Literally  thousands  of  processes 
(both  formal  and  informal)  are  executed  by  division  entities  on  a  daily  basis.  In  order  to 
control  the  different  processes,  battalion  through  division  size  organizations  break  down 
these  operations  into  four  primary  task  groups.  A  responsible  officer  is  chosen  by  the 
commander  to  lead  these  operational  groups  at  each  entity  level.  These  groups  are 
labeled  staff  elements  and  are  numbered  one  through  four  with  five  (civil  affairs)  and  six 
(communications  and  computers)  located  at  division  level  and  above  units.  Figure  3.2 
depicts  the  hierarchical  structure  of  a  typical  staff.  The  Chief  of  Staff  (division  level  and 
above)  or  Executive  Officer  (XO)  (brigade  level  and  below)  presides  over  the  staff  at 
each  entity  level  dovm  to  and  including  battalions.  There  are  a  total  of  seven  brigades 


Figure  3.2.  An  Army  Staff 
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and  twenty-three  battalions  in  the  40*'’  division.  Each  of  them  possesses  a  staff  similar  to 
the  one  depicted  in  Figure  3.2. 

Below  is  a  very  brief  description  of  each  staff  element’s  area  of  responsibility. 

The  intent  is  to  give  the  non-military  reader  an  introduction  to  military  staff  areas  of 
responsibility. 

•  G-l/S-l(Personnel):  Responsible  for  all  personnel  actions  in  the  division,  to 
include  awards,  promotions,  pay  inquiries,  and  personnel  replenishment 
planning  in  a  combat  environment.  If  it  has  to  do  with  persoimel  actions,  it  is 
the  G-l/S-l’s  area  of  responsibility. 

•  G-2/S-2(InteUigence):  The  intelligence  section  of  an  organization  focuses  on 
the  threat.  The  threat  may  be  local  gangs  that  present  a  potential  threat  to  a 
military  installation  or  an  enemy  combat  foe  with  armored  tanks  and  artillery 
pieces.  The  G-2  is  responsible  for  keeping  the  commander  and  the  rest  of  the 
staff  abreast  of  the  capabilities  and  limitations  of  the  threat  and  what  the  threat 
is  doing.  In  a  garrison  environment,  the  G-2/S-2  is  responsible  for  security 
awareness  and  measures  to  combat  the  threat  in  that  environment. 

•  G-3/S-3(OPS/Traming):  The  G-3  is  the  operations  and  training  officer. 
Planning,  preparing  for,  and  executing  training  events  is  one  of  the  G-3/S-3s 
many  responsibilities.  The  OPS/training  officer’s  focus  during  peacetime  is 
on  the  unit’s  Mission  Essential  Task  List  (METL).  A  unit’s  METL  are  those 
tasks  it  must  be  able  to  perform  in  order  to  insure  a  combat  level  of  readiness. 
The  G-3/S-3  writes  the  operations  orders  (OPORDS),  issues  fi*agmentary 
orders  (updates  to  OPORDS)  and  coordinates  the  other  staffs  activities  in  the 
absence  of  the  Chief  of  Staff. 

•  G-4/S-4  (Logistics):  The  logistics  officer  is  responsible  for  all  logistical 
matters  in  the  division.  The  G-4  arms,  fixes,  fuels,  feeds,  houses,  and 
transports  the  division.  Like  the  odier  staff  elements,  the  G-4  is  heavily 
involved  in  planning  operations.  In  order  for  the  G-3  to  consider  an 
operationally  feasible  plan,  the  G-4  must  certify  that  the  plan  is  logistically 
supportable. 

The  40*'’  has  subordinate  organizations  in  five  different  states  (Arizona,  California, 
Montana,  Utah,  and  North  Dakota).  The  40*'’  division  accounts  for  nearly  eighty  percent 
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Figure  3.3.  40***  Division  Units  in  California  [3.2] 


4.  Mission 

The  40***  Division  has  a  dual  mission.  Their  federal  mission  is  to  provide  combat 
ready  forces  to  the  Department  of  Defense.  In  order  to  do  this,  the  division  conducts 
pre-mobilization  training  to  maintain  a  level  of  readiness  so,  when  called  upon  to 
mobilize,  she  can  do  so  on  short  notice.  Once  mobilized,  the  division  must  conduct  the 
necessary  post  mobilization  training  to  further  prepare  itself  to  deploy,  fight,  and  win. 

The  division’s  other  mission  is  to  provide  military  support  to  civil  authorities. 
The  division  answers  to  the  Office  of  The  Adjutant  General  (OTAG)  and  to  the  state’s 
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Governor.  Both  are  located  at  the  state’s  capitol  in  Sacramento.  The  state  of  California 
is  the  most  disaster-prone  state  in  the  nation.  The  division’s  mission  siunmary  list  for 
1996  include  600  counter-drug,  33  emergency  shelter,  21  fire,  1 1  search  and  rescue,  3 
flood,  and  16  other  support  type  missions  [3.3]. 

C.  RESERVE  COMPONENT  AUTOMATION  SYSTEM 

1.  Background 

The  Reserve  Component  Automation  System  (RCAS)  is  an  Army  National  Guard 
and  Reserve  component  sustaining  base/office  automation  system.  The  system  was 
designed  to  meet  the  day-to-day  office  automation  requirements  to  the  Army’s  reserve 
component.  The  design  of  the  system  significantly  enhances  the  reserve  component’s 
mobilization  preparedness  and  execution. 

In  February  1995,  amidst  reports  indicating  program  problems  (i.e.,  cost  and 
schedule  overruns,  system  performance  problems,  customer  dissatisfaction).  Lieutenant 
General  Edward  D.  Baca,  Chief  of  the  National  Guard  Bureau,  assembled  a  “Red  Team” 
to  conduct  an  objective  assessment  of  the  program  status  of  the  RCAS.  The  team  was 
chartered  to  identify  problem  areas  and  to  develop  courses  of  action  necessary  to  put  the 
program  back  on  a  reasonable  development  and  implementation  path.  The  “Red  Team” 
recommended  significant  changes  in  the  RCAS  program  in  many  program  areas  [3.4]. 
Following  the  recommendations,  the  RCAS  Validation  Assessment  Team  (VAT)  was 
established  to  validate  and  substantiate  the  Red  Team’s  findings.  The  charter  of  the  VAT 
was  to  identify,  assess,  and  develop  a  complete  system  solution  which  was  consistent 
with  the  Red  team’s  recommendations  and  satisfied  user-defined  requirements  of  the 
United  States  Army  Reserve  Component,  within  budget.  [3.5] 
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In  order  to  give  the  reader  a  perspective  of  where  the  program  was  when  General 
Baca  called  for  the  assessment,  the  following  bullets  are  provided  which  characterize  the 
program  at  that  point  in  time: 

•  Fielding  of  the  original  system  began  in  1987.  Nearly  thirty  percent  of  the 
projected  4000  plus  sites  had  been  fielded  when  deployment  of  the  system 
was  halted  in  1995.  California  was  the  first  state  fielded.  A  total  of  387  units 
and  activities  were  fielded  with  the  original  RCAS  in  California. 

•  Difficulties  in  managing  the  users  and  their  needs  and  expectations  led  to 
changes  in  the  requirements,  which  ultimately  impacted  software  design  goals 
and  objectives.  TTiis  resulted  in  a  projected  two  year  delay  in  the  completion 
of  the  first  block  of  software. 

•  The  original  architecture  is  a  Unix  based  client/server  environment.  The 
system  called  for  x-terminal  client  machines  with  no  local  capability  (i.e., 
resident  CPU)  for  application  processing.  There  were  complaints  about  the 
user’s  familiarity  wiA  Unix  based  applications  and  the  Unix  command  line, 
particularly  for  soldiers  who  only  drill  one  weekend  a  month. 

•  The  system  was  used  primarily  as  an  e-mail  system.  There  were  5  regional 
mail  hubs,  which  routed  mail  traffic  down  to  the  unit  level.  Each  unit 
maintained  its  own  dedicated  Unix  based  server.  The  original  solution 
required  units  to  dial-in  to  one  of  the  five  regional  mail  hubs  in  order  to 
upload  and  download  mail.  The  original  architecture  using  these  dedicated 
Unix  servers  with  little  or  no  redundancy  at  some  sites  was  very  susceptible  to 
single  point  failures. 

•  The  original  system  architecture  called  for  a  distributed  database  with  data 
servers  physically  located  at  the  unit  or  end  user  level.  The  initial  plan  called 
for  the  procurement  and  implementation  of  the  anticipated  4,700  locations 
with  costly  specialized  hardware  and  software.  An  illustration  of  the  original 
architecture  is  presented  in  Figure  3.4. 
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Figure  3.4.  RCAS  Original  Architecture 

At  the  time  the  “Red  Team”  was  formed,  the  RCAS  program  was  suffering  from 
not  being  in  tune  with  the  requirements  and  needs  of  the  customer. 

2.  Scope 

The  Reserve  Component  Automation  System  is  a  2.5  billion-dollar  program. 
Rather  than  dwell  on  the  problems  the  program  has  suffered  in  the  past,  a  chose  was 
made  to  look  to  the  program’s  future  and  the  recommendations  made  by  the  Red  team  and 
the  VAT.  On  19  July,  1995,  the  RCAS  General  Officer  Steering  Committee  (GOSC),  the 
overall  decision-making  body  for  the  RCAS,  directed  the  RCAS  Program  Management 
Office  (PMO)  to  implement  the  Red  TeamA^AT  recommendations  [3.6]. 
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The  major  restruchmng  of  the  RCAS  program  in  1995,  based  on  the  assessment 
team’s  recommendations  caused  significant  changes  in  the  way  the  program  was  being 
run.  The  focus  of  the  remainder  of  the  discussion  on  the  RCAS  system  centers  on  the 
following  areas:  Red  TeamA^AT  recommendations  in  the  areas  of  system  architecture, 
system  data  and  applications,  and  system  deployment. 

3.  System  Architecture  [3.7] 

The  Red  TeamA^AT  established  objectives  before  they  considered  different 
architectural  and  design  alternatives  for  the  new  system.  Those  objectives  included: 

•  Use  of  Industry/  DOD  standards 

•  Maximum  use  of  Commercial  Off  The  Shelf  (COTS)  and  Government  Off 
The  Shelf  (GOTS)  hardware  and  software 

•  Meet  the  needs  of  the  users 

•  Use  mainstream  technology 

•  Use  scalable  components  with  scalable  architecture 

•  Make  architecture  adaptable  to  rapidly  changing  technology 

•  Ensure  compliance  with  the  Army’s  Technical  Architecture  (ATA)  and 
Defense  Information  Infi-astructure’s  Common  Operating  Environment  (COE) 

•  Make  the  architecture  data-centered 

The  resultant  architecture  recommended  by  the  VAT  and  approved  by  the  RCAS 
General  Officer  Steering  Committee  (GOSC)  is  in-line  with  the  objectives  established 
prior  to  architecture  formulations.  The  architecture  can  be  characterized  as  a 
server/workstation  architecture  and  is  presented  in  a  very  broad  view  in  Figure  3.5. 

Scalability  is  probably  the  first  noticeable  characteristic  in  Figure  3.5.  Because  of 
the  different  sized  organizations,  the  sites  are  configurable  to  suit  the  needs  of  the  user. 
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Figure  3.5.  RCAS  Server/Workstation  Environment  [3.8] 


Most  State  Area  Command  (STARC),  Regional  Support  Command  (RSC),  and  Direct 
Reporting  Commands  (DRC)  are  considered  large  sites  (76+  workstations).  These  major 
hubs  provide  the  WAN  connectivity  to  other  STARCs,  RSCs,  and  DRCs.  Other 
configmable  variants  include  medium  sites  (17-75  workstations),  medium  sites  (9-16 
workstations),  and  small  sites  (1-8  workstations). 

The  server  side  of  the  server/workstation  architecture  is  based  on  Microsoft’s 
Windows  NT  Server  4.0,  which  is  a  network  operating  system.  The  NT  Servers  which 
are  located  throughout  the  architecture  provide  such  system  functions  as  centralized 
administration  and  management,  e-mail,  LAN  printing,  file  sharing,  configuration 
management,  virus  protection  management,  and  system  and  file  security  [3.9]. 


The  implementation  of  any  Windows  NT  server  design  is  based  on  a  domain 
structure.  A  domain  is  a  set  of  servers,  defined  as  a  logical  group,  which  holds  the  user 
accoimt/domain  database.  A  domain  is  the  basic  unit  of  centralized  administration  and 
security.  NT  server  provides  the  connectivity,  reliability  and  availability,  base  system 
services  and  administrative  tools  necessary  to  deliver  critical  information  across  a  large 
distributed  network  of  computers.  [3.10] 

All  workstations  in  the  workstation/server  environment  are  based  on  Personal 
Computer  (PC)  architecture  with  a  Pentium  processor,  16MB  RAM,  an  IDE  Enhanced 
controller,  and  a  1  GB  hard  disk.  The  workstation  operating  system  is  Microsoft 
Windows  NT  workstation.  NT  workstation  provides  security  at  the  C2  level  which 
includes  Identification  and  Authentication  (I«feA),  Discretionary  Access  Controls  (DAC), 
Audit  and  Object  Reuse.  This  provides  users  with  the  capability  to  restrict  access  to  data 
on  a  read/write  basis  and  administrators  with  the  ability  to  monitor  system  usage.  The 
Office  Automation  (OA)  suite  (Microsoft  Office)  has  the  fiiendly  graphical  user  interface 
(GUI)  that  users  are  familiar  with.  All  the  application  files  in  the  OA  suite  can  be 
attached  to  a  mail  message  using  Multi-purpose  Internet  Mail  Extension  (MIME) 
(Chapter  2)  and  sent  using  the  resident  mail  client.  A  closer  look  at  the  architecture 
indicates  the  RCAS  will  operate  as  two  separate  systems,  one  for  classified  or  “Red” 
processing  and  one  for  unclassified  or  “Black”  processing.  Figure  3.6  shows  the  Red 
system  solution. 
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Figure  3.6.  RCAS  Red  Architecture  Solution 

The  “Red  System”  is  characterized  by  its  use  of  secure  data  devices  (i.e.,  STU- 
III)  operating  at  each  entity  level  between  transmitting  and  receiving  units.  The 
architecture  calls  for  stand-alone  workstations  at  all  echelons  with  removable  media  (i.e., 
hard  disks). 

The  “Black  System”  solution  side  of  the  RCAS  system  is  depicted  in  Figure  3.7. 
The  NIPRNET  is  DOD’s  unclassified  but  sensitive  Internet  Protocol  Router  Network  and 
serves  as  the  network  backbone  for  RCAS.  The  RCAS  is  vulnerable  in  two  areas.  First, 
the  network  has  no  means  to  safeguard  the  integrity  of  traffic  and  protect  it  from 
disclosure.  The  second  is  that  RCAS  nodes  connected  to  the  NIPRNET  are  vulnerable  to 
attack  from  the  Internet. 
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In  order  to  protect  the  integrity  of  traffic,  the  architecture  calls  for  the  use  of 
Digital  Encryption  Standard  (DES)  packet  encryptors.  Every  workstation  will  be 
equipped  with  PC  card  slots.  The  DES  packet  encryption  devices  are  credit  card  size  and 
uniquely  identify  message  traffic  senders  and  receivers.  The  cards  are  inserted  into  the 
card  slots  in  order  to  encrypt  and  decrypt  messages.  A  COTS  firewall  at  the  RCAS 
Network  hub  will  provide  managed  access  to  the  RCAS  system  from  the  internet. 


Figure  3.7.  RCAS  Black  Solution  Architecture  [3.12] 

4.  System  Data  and  Applications 

If  you  recall,  one  of  the  objectives  of  the  VAT,  when  considering  the  RCAS,  was 
to  make  the  architecture  data  centered.  The  power  and  utility  provided  a  user,  when  able 
to  query  database  management  systems,  can  not  be  imderestimated.  The  ability  to  access 
local  or  remote  databases  provides  the  user  with  a  powerful  decision  support  tool.  Figure 
3.8  provides  an  illustration  of  how  the  “data  centered”  components  will  be  incorporated 
in  the  RCAS  architecture. 
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LOCAL  REPLICATION 


for  query  and  local  reporting 

Figure  3.8.  RCAS  Database  Architecture  [3.13] 

A  DataBase  Management  System  (DBMS)  is  established  at  State  Area 
Commands  (ST ARC)  and  Major  United  States  Army  Reserve  Commands  (MUSARC). 
The  DBMS  at  this  level  will  also  be  known  as  the  DataBase  Of  Record  (DBOR).  These 
DBORs  will  be  tied  to  other  replicated  hosts  including  hosts  at  the  National  Guard 
Bureau  (NGB),  the  United  States  Army  Reserve  Command  (USARC)  and  Mobilization 
stations  throughout  the  guard  and  reserves.  Applications  residing  on  local  level  machines 
will  allow  the  local  user  to  access  and  query  the  DBOR.  Batched  transactions  will  allow 
the  DBOR  to  update  the  DBMS  at  the  intermediate  (Brigades  and  Divisions)  and  lowest 
levels,  to  provide  the  user  with  an  up-to-date  replication  of  the  DBOR.  This  provides  the 
user  with  a  local  query  and  reporting  capability. 
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5. 


RCAS  Deployment 


Deployment  of  the  system  is  defined  as  those  functions  necessary  to  manage  and 
distribute  RCAS  automated  data  processing  (ADP)  hardware,  telecommunications 
equipment,  and  the  office  automation  or  pre-loaded  software  to  the  designated  (4,000 
plus)  end  user  sites  or  locations  [3.13]  Figure  3.9  gives  the  locations  of  the 
approximately  4021  RCAS  sites,  which  include  10540  units.  Figure  3.10  gives  echelon 
unit  quantities  by  site  size  and  totals  the  number  of  sites,  units,  and  workstations. 


Figure  3.9.  RCAS  Deployment  Site  Location  [3.14] 
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Figure  3.10.  RCAS  Unit  Distribution  [3.15] 


D.  CURRENT  STATUS 

The  intent  of  this  section  is  to  give  the  reader  a  current  status  of  the  “post-old 
RCAS”  and  “pre-new  RCAS”  situation  in  the  state  of  California.  As  was  mentioned 
previously,  California  was  the  first  state  in  the  U.S.  fielded  with  the  old  RCAS  system. 
The  fielding  of  387  Unix  based  servers  with  ancillary  equipment  (i.e.,  x-terminals. 
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printers,  etc.)  to  as  many  units  and  activities,  was  done  at  an  estimated  cost  of  nearly 
$100  million.  The  state's  number  one  priority  for  fielding  the  old  RCAS  system  earned  it 
a  very  low  priority  (last  state  to  be  fielded)  for  federal  funding  of  the  new  system. 
Information  management  representatives  from  the  state  headquarters  do  not  expect 
program  funding  for  equipment,  installation,  fielding,  and  training  until  2^  Quarter  of 
fiscal  year  1998.  The  387  units  and  activities  throughout  the  state  were  totally  reliant  on 
the  server-based  office  applications  when  the  decisions  were  made  in  1995  to  shift  to  a 
PC  based  workstation/  NT  server  environment.  Very  few  of  the  organizations  had  PCs  to 
conduct  office  administration  tasks.  The  ability  to  share  data  electronically  with  adjacent 
units,  via  a  network,  was  eliminated  when  the  Rocklin  regional  mail  hub  was  shut  down 
in  October,  1996.  Since  then,  the  state  and  the  division  have  aggressively  pursued 
information  operations  initiatives  with  state  funding  to  improve  their  ability  to  pass 
information  in  a  quick  and  efficient  manner.  The  state's  initiatives  are  in-line  with  the 
architectural  requirements  for  new  RCAS  system,  (i.e.,  MS  NT  based,  MS  Office,  etc.) 
The  state  is  posturing  itself  for  new  RCAS  using  state  funding  to  come  up  with  interim 
solutions  to  their  degraded  information  operations.  Some  of  the  initiatives  that  have  been 
enacted  include: 

•  The  purchase  and  issue  of  two  (in  some  cases  only  one)  or  more  PC 
workstations  to  each  of  the  387  units  and  activities  throughout  the  state 

•  The  development  of  a  web-based  Division  Intranet  (this  thesis)  which  has 
since  been  expanded  into  a  State-wide  Intranet  called  the  “Grizzly  Net” 

•  The  establishment  of  a  Primary  Domain  Controller  (PDC)  at  the  state 
headquarters  which  will  be  the  PDC  for  the  state's  Wide  Area  Network 
(WAN) 
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•  The  establishment  of  six  Back-up  Domain  Controllers  (BDC),  one  each  at  the 
following  locations:  San  Francisco,  Stockton,  San  Luis  Obispo,  Los  Angeles, 
and  Sacramento.  Each  of  these  BDC  sites  will  have  a  dedicated  T-1 
connection  with  the  PDC  in  Sacramento.  Each  of  the  BDC  sites  is  being 
equipped  with  a  modem  bank  to  allow  units  without  a  dedicated  line 
connectivity  to  the  network. 

•  The  establishment  of  1 1  subnets  (organizations  with  17-99  workstations)  off 
the  states  WAN 

•  The  development  of  a  tactical  network 

These  are  just  some  of  the  many  initiatives  ongoing  in  the  California  National 
Guard  to  improve  the  current  state  of  information  operations  and  to  posture  itself  for 
program  funding  and  fielding  of  the  RCAS  system  in  2"**  Quarter  of  FY98. 


35 


IV.  THE  PROTOTYPING  PROCESS 


A.  INTRODUCTION 

To  better  understand  the  potential  contribution  the  prototyping  process  can  have 
on  development  of  a  prototype,  there  must  first  be  a  definition  of  what  the  process  entails. 
Next,  a  review  of  the  project  scope  and  the  current  operating  environment  will  set  the 
stage  for  determining  how  best  to  modify  the  prototype  process  to  meet  the  division’s 
needs. 


B.  THE  PROTOTYPE  DEVELOPMENT  MODEL 

A  prototype  is  defined  as  a  preliminary  working  version  of  an  information  system 
for  demonstration  and  evaluation  purposes.  It  follows  that  prototyping  may  be  defined  as 
the  process  of  building  an  experimental  system  quickly  and  inexpensively  for 
demonstration  and  evaluation  so  that  users  can  better  determine  information  requirements 

[4.1] .  The  primary  purpose  of  the  prototyping  process  is  “to  reduce  time  and  expense  in 
building  quality  systems”  and  “mandates  a  philosophy  of  incremental  system 
development  that  includes  end  users  in  the  assessment  of  emerging  system  capabilities” 

[4.2] .  Understanding  this  process  and  its  potential  benefits  and  pitfalls  can  best  be 
accomplished  after  a  review  of  the  traditional  waterfall  development  model. 
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Figure  4.1  displays  the  typical  steps  in  the  waterfall  model.  This  display  shows 
seven  steps  required  in  developing  a  business  application,  with  each  step  being  iterative 
with  the  step  before  it.  This  is  to  say  that  the  product  is  verified  as  it  moves  from  one 
phase  to  another,  and  validated/corrected  after  arrival  at  each  new  phase  [4.3]. 

Because  the  waterfall  model  has  been  in  widespread  use  since  the  1970’s,  its 
advantages  and  disadvantages  have  been  widely  documented.  The  model  is  well  known 
for  bringing  much  needed  organization  to  very  large  projects.  The  rigorous  execution  of 
each  phase  coupled  with  the  validation  and  verification  processes  often  leads  to 
monumental  management  effort,  high  costs,  project  delays,  high  maintenance  costs, 
obsolete  products  and,  worst  of  all,  products  which  no  longer  address  the  central  needs  of 
the  customer  [4.1, 4.3]. 
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By  comparison,  the  basic  prototype  model  presented  in  Figure  4.2  is  designed  to 
include  user  feedback  early  in  the  development  cycle.  The  first  step  places  emphasis  on 
capturing  the  most  basic  of  customer  requirements  to  be  used  in  developing  the  initial 


Figure  4.2.  The  Prototype  Model  [4.1] 


prototype.  Step  two  also  involves  speed.  The  developer  need  quickly  create  a  working 
prototype,  even  if  it  is  a  shell  with  only  restricted  application,  and  return  it  to  the 
customer.  Next,  the  end  user  will  use  the  prototype  and  make  recommendations  for 
revision.  Step  four  involves  revision  of  die  prototype  per  the  user’s  requirements. 
Completion  of  this  step  is  followed  by  an  iterative  move  back  to  step  three  imtil  the 
customer  is  satisfied  that  all  requirements  for  the  system  have  been  met  [4.4]. 

Philips  electronics  envisaged  the  following  benefits  fi'om  use  of  rapid  prototyping 
in  software  development  for  their  products  [4.5]: 
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•  Early  Customer  involvement 

•  Improved  specification  quality 

•  No  ‘dead-end’  demonstrations 

•  Shorter  time  to  first  product  drops 

•  User  fiiendly  systems  to  the  customer 

•  Less  defects  in  latter  phases  of  the  lifecycle  (and,  thus,  lower  maintenance 
costs) 

Additional  benefits  include  [4.6, 4.7, 4.8, 4.9]: 

•  Better  user  interface  development 

•  Continuous  customer  involvement 

•  Reduced  development  costs 

•  Very  well  suited  for  smaller  applications 

•  Ensures  nucleus  of  system  is  right  (i.e.,  clarifies  requirements  and  more 
exactly  meets  users  need) 

•  Reduced  levels  of  effort  for  staff 

•  Increased  user  enthusiasm 

•  Validation  and  verification  are  inherent 

•  Evolutionary  nature  enhances  flexibility  and  scalability  in  a  rapidly 
changing  environment 

This  last  point  is  a  key  consideration  in  choosing  to  use  the  prototype  process.  By 
recognizing  the  protot5q3e  process  as  involving  the  capture  of  human  activity  systems  vice 
as  a  science  or  engineering  tool  [4.10],  the  processes  suitability  in  situations  with  ill 
defined  or  rapidly  changing  environments  may  be  viewed.  Exposing  the  protot5q)e  to 
the  actual  environment  can  be  seen  as  a  learning  method.  As  displayed  in  Figure  4.3 
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[4.1 1],  this  “learning  process”  is  incremental  in  nature,  as  the  product  is  iteratively 
reconciled  against  customer  needs.  It  is  this  incremental  learning  which  allows  the 


Figure  4.3.  Nested  Development  Loop  [4.11] 

prototyping  process  to  respond  to  rapid  change  in  the  environment,  providing  maximum 
flexibility  in  the  maintenance  phase  of  the  lifecycle  [4.12].  The  iteration  concept  will  be 
explored  more  fully  later  in  the  chapter. 

Lest  the  prototyping  process  appear  to  be  a  panacea,  the  following  list  of  potential 
problems  is  presented  [4.13, 4.14, 4,15, 4.16]: 

•  Essential  elements  in  system  development  may  be  glossed  over  (i.e., 
documenting  system) 

•  Prototype  may  prove  functionalities  that  are  unattainable  under  real  time 
usage  of  assets 

•  May  lead  to  end  user  misunderstanding  (user  doesn’t  understand  ‘Under 
Construction’  look  and  feel) 

•  Clean  up  of  prototype  may  not  occur  (i.e.,  leaving  imused/out-dated  materials 
in  place) 

•  Prototype  may  capture  only  rudimentary  requirements  (i.e.,  incomplete 
iteration) 

•  Difficult  to  maintain  user  enthusiasm,  especially  in  the  face  of  overselling  the 
prototyping  process.  Can  lead  to  dissatisfaction 

•  Difficult  to  plan  and  control;  not  suitable  for  large  projects 
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•  Design  standards  may  be  hard  to  enforce 

•  Potential  for  loss  of  information  security  (Security  measures  discussed  in 
Chapter  VII) 

Another  well-known  pitfall  is  that  throwaway  prototypes  often  are  not  thrown 
away.  This  raises  the  discussion  of  throwaway  prototyping  verses  evolutionary 
prototyping.  The  key  advantage  to  creating  a  throwaway  prototype  is  that  actual 
requirements  are  still  gathered  via  prototyping,  but  design  is  conducted  separately,  under 
more  structured  conditions.  This  action  ensures  better  documentation,  but  earns  the 
dangers  inherent  in  traditional  methods.  The  evolutionary  process  strives  to  develop  a 
working  model  that  will  become  the  desired  system,  and  is  the  basis  for  most  of  this 
chapter’s  material  [4.17].  As  mentioned  in  the  above  list,  evolutionary  prototyping  can 
suffer  degradation  of  quality  attributes  such  as  performance,  design  quality  and 
maintainability  [4.18].  In  this  instance  case,  the  throwaway  prototype  option  was 
rejected  for  reasons  that  will  be  discussed  in  Chapter  VI. 

C.  SCOPE 

The  scope  of  the  proposed  prototype  encompasses  the  building  of  a  baseline 
Intranet  for  the  40*  Mechanized  Infantry  Division.  The  prototype  includes  web  pages 
down  to  the  Battalion  level,  designed  in  a  standardized  manner.  Rather  than  a  “do  all, 
end  all”  system,  the  prototype  will  contain  only  some  key  functions  identified  in  Chapter 
VI,  and  will  be  turned  over  to  the  end  user  for  continuous  revision  by  members  of  the 
division  as  described  in  paragraph  D  and  Figure  4.4. 
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Instead  of  the  fourth  generation  tools  typically  used  in  prototype  development, 
this  prototype  will  be  built  vdth  Commercial-Off-The-Shelf  (COTS)  web  editors,  word 
processors  and  database  suites  in  v^dde  use  by  the  members  of  the  division. 

D.  CURRENT  INFORMATION  OPERATIONS 

The  current  means  of  managing  information  is  time  honored  and  effective,  if  not 
efficient.  The  predominant  information  exchange  capability  between  and  within  umts  is 
the  telephone.  With  the  addition  of  the  facsimile  machine,  this  medium  has  expanded 
from  a  coordination  tool,  to  one  capable  of  transporting  all  manner  of  management 
information.  MUX  and  FM  facsimile  equipment  now  available  at  the  division  level 
ensure  this  capability  is  available  even  in  the  field  environment. 

Computers  have  also  aided  dramatically,  enabling  an  interactive  medium  via  the 
electronic  file.  Information  management  systems  have  been  developed  for  all  major 
resource  management  programs  to  include  supply,  maintenance,  personnel  and 
operations/training  control.  These  systems  allow  inter-echelon  exchange  of  information 
via  file  passing/updating  by  disk  or  download. 

Guard  Mail,  U.S.  Mail,  and  expedited  shipping  means  are  also  available  for  the 
physical  transfer  of  paper  and  disk  versions  of  information. 

Finally,  meetings  and  other  face  to  face  coordination  are  still  a  highly  effective 
means  of  ensuring  information  is  passed  correctly,  requirements  are  understood  and 
orders  will  be  complied  with. 

As  mentioned,  these  methods  may  be  used  effectively,  but  suffer  in  terms  of 
efficiency.  Among  the  limitations  of  these  methods  is  susceptibility  of  physical  medium. 
While  in  transit,  reports  and  other  forms  of  information  may  be  exposed  to  wrong  parties 
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as  control  of  the  medium  is  lost  after  shipping/faxing.  Anyone  familiar  with  office 
management  doubtless  can  relate  stories  of  lost  phone  messages,  compromised 
information  files  and  unreceived  materials. 

Some  important  materials  need  not  only  be  hand  delivered,  but  also  will  require 
on-site  review  to  ensure  adequate  and  correct  submittal.  An  example  would  be 
processing  of  unit  readiness  information  or  the  coordination  meetings  prior  to  a  drill 
period.  The  costs  involved  in  this  t5q)e  of  interchange  are  twofold.  First,  the  actual  cost 
of  traveling,  be  it  borne  by  the  unit  (TAD  funds),  or  the  individual  soldier.  Second,  the 
requirement  to  be  at  the  same  place  and  time  represents  a  major  opportunity  cost, 
especially  when  travel  time  is  considered. 

Similarly,  phone  and  inter-unit  meetings  suffer  from  lost  opportunity  costs. 

While  the  timing  of  a  meeting  or  a  phone  call  may  be  optimal  for  the  initiator,  the  other 
participant(s)  may  not  be  prepared  to  deal  with  the  issue  at  hand,  or  may  have  more 
pressing  requirements.  Moreover,  while  methods  like  electronic  file  passing  allow 
interaction,  it  is  not  real-time  interaction.  In  short,  these  “information  push”  methods  do 
not  allow  optimization  of  information  and  personnel  across  time  and  space  for  all  parties. 
E.  ADAPTATION  OF  THE  PROTOTYPING  PROCESS  FOR  A  MILITARY 

INTRANET 

Perhaps  the  paramount  requirement  in  successfully  adapting  the  prototype  process 
for  any  Intranet,  military  or  otherwise,  is  to  recognize  that  the  process  will  be  continuous 
throughout  the  life  of  the  Intranet.  Because  content  requirements,  intended  purpose  of 
the  Intranet,  and  number  and  types  of  users  will  change  with  the  organizational 
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environment,  the  flexibility  provided  by  the  nested  development  loop  identified  in  Figure 
4.3  will  prove  invaluable  in  providing  the  needed  flexibility. 


TOTAL  SCOPE  :  FULL  SCALE  SYSTEM  FUNCTIONALITY 


OROWTH  BY 
EXTGNflKW 


Figure  4.4.  Migration  of  Scope  [4.19] 

As  mentioned  above,  the  prototype  delivered  to  the  40®  Division  provided  only 
minimal  functionality  and  represents  the  prototype  initial  effort  identified  in  Figure  4.4  . 
It  will  now  become  incumbent  upon  the  division  staff  to  expand  the  prototype  via  what  is 
dubbed  Black  Border  Management  [4. 19].  A  section  in  Chapter  VII  will  be  devoted  to 
the  role  of  the  Division  Information  Management  Advisory  Council  (DIMAC)  in 
managing  and  controlling  this  growth.  Initially,  the  DIMAC  will  set  basic  policy  and 
approve  changes  to  the  prototype  as  depicted  in  Figure  4.5. 


45 


PROBLEM  REPORTS  AND 
ENHNACEMENT  REQUESTS 


FUNCTION/ 

CONTENT 

REQUESTS 


Figure  4.5.  DIMACRole 

As  the  basic  policies  and  procedures  are  identified,  responsibility  for  development 
and  maintenance  of  content  will  shift  to  the  end  user.  At  this  stage,  the  prototyping 
process  matures  into  an  end-user  development  process,  allowing  the  individual  units, 
commanders  and  staff  sections  to  provide  and  manage  the  content  they  deem  most 
necessary  imder  a  changing  enviromnent.  This  represents  the  major  content  change  to  the 
standard  prototyping  process  identified  in  Figure  4.2  above.  It  should  be  noted  that  the 
DIMAC  still  maintains  control  over  the  basic  prototype  design  and  content  issues  as 
shown  in  Figure  4.6,  thus  providing  the  division  commander  control  over  the  Intranet 
prototype. 

F.  CONCLUSION 

The  prototype  model  has  been  introduced  in  a  manner  which  provides  comparison 
to  more  rigid  development  procedures.  The  major  advantages,  and  those  important  to  the 
Intranet  project,  are  scalability,  better  user  interface  and  satisfaction,  and  more  flexibility 
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Figure  4.6.  Modified  Prototype  Model 


in  the  face  of  uncertain  needs.  The  last  advantage  is  enhanced  when  one  realizes  that  the 
Intranet  content  will  be  ever  changing,  relying  on  end-user  development  after  delivery, 
and  providing  considerable  flexibility. 
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V.  IDENTIFICATION  OF  BASIC  REQUIREMENTS 


A.  INTRODUCTION 

This  chapter  will  explore  the  background  and  relationship  developed  with  the 
sponsor  and  the  40*^  Infantry  Division  (Mechanized),  the  methodology  used  for  gathering 
requirements,  and  a  comprehensive  discussion  of  the  requirements  used  to  generate  the 
prototype  discussed  in  Chapter  VI. 

B.  BACKGROUND 

In  October  1996,  the  development  team  witnessed  a  demonstration  of  an  Intranet 
designed  for  a  Naval  Postgraduate  School  application.  This  demonstration  sparked  an 
interest  in  the  Intranet  development  technology  and  process.  In  an  effort  to  find  a 
relatively  local  military  sponsor,  the  team  visited  a  California  National  Guard  tank 
battalion  unit  based  at  the  former  Fort  Ord,  California.  Diuing  this  visit,  the  team 
discovered  the  shortfall  in  network  computing  resulting  from  the  closing  of  the  RCAS 
system  as  discussed  in  Chapter  I.  It  was  also  discovered  that  the  40**^  Infantry  Division 
(Mechanized)  was  in  the  process  of  distributing  personal  computers  and  establishing  a 
dial-in  network,  and  points  of  contact  were  gathered  which  eventually  led  the  team  to 
LTC  Rod  Barham,  the  project  sponsor. 

Initial  contact  was  made  wifii  LTC  Barham,  who  proved  more  than  interested  in 
developing  a  web  for  use  by  his  division,  and  spoke  of  an  ongoing  effort  to  create  a 
division  BBS.  A  system  requirements  meeting  was  scheduled  for  December,  resulting  in 
the  trip  report  presented  in  Appendix  A.  After  discussions  with  LTC  Barham’s  BBS 
project  point  man,  SSG  Greg  Holmes,  it  became  obvious  that  the  focus  of  effort  to  that 
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point  was  to  set  up  the  dial-in  network  to  share  information  from  the  Logistics  Automated 
System  Support  Office  (LASSO)  and  establish  e-mail  accounts  for  key  users.  The 
broader  issue  of  a  division-wide  information  distribution  system  was  not  yet  being  fully 
addressed  by  these  efforts  [5.1]. 

C.  PERSPECTIVE 

Clearly,  what  was  needed  was  a  design  plan  incorporating  the  entire  division,  and 
absorbing  the  LASSO  efforts  as  a  portion  of  the  larger  system.  The  team  discussed  the 
need  with  LTC  Barham,  and  it  was  agreed  that  this  was  the  correct  course  of  action  to 
take.  However,  even  the  most  cursory  review  of  the  information  distribution  system 
currently  in  use  by  the  division  indicated  a  problem  scope  well  beyond  the  capabilities  of 
a  single  thesis  team.  Accordingly,  it  was  decided  to  limit  the  scope  of  the  project,  as 
discussed  in  Chapter  IV,  and  three  requirement  areas  were  identified.  First,  a  full  scale 
Intranet  static  design  would  need  to  be  completed.  Second,  additional  functionality  will 
be  provided  on  a  limited  scale.  Lastly,  an  effort  would  be  made  to  arrange  for  follow-on 
students  to  continue  to  address  functionality  issues  with  the  division.  While  this  last 
requirement  was  successfully  met,  it  is  not  the  subject  of  this  thesis  and  will  not  be 
discussed  further.  However,  the  first  two  requirements  will  be  more  fully  explained  in 
the  below  paragraphs. 

D.  REQUIREMENTS 

Chapter  IV  briefly  delved  into  the  vast  variety  of  current  information  management 
methods  practiced  at  the  division  and  discussed  the  key  limitation  of  the  lack  of  ability  to 
optimize  information  and  human  resources  across  the  time  and  distance  continuum. 

While  the  information  distribution  systems  were  too  many  to  diagram  and  consider,  it 
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became  apparent  that  the  basic  design  for  the  proposed  Intranet  would  need  to  provide  the 
means  of  augmenting  or  replacing  some  of  these  methods  and  systems.  To  meet  this 
requirement,  the  design  would  need  to  move  the  user  from  an  initial  “home  page” 
through  the  various  layers  of  command,  with  links  to  appropriate  staff  sections  and 
activity  pages  at  each  layer.  Further,  it  was  decided  that  the  Intranet  design  should  be 
simple,  have  a  consistent  look  and  feel  throughout,  and  be  free  of  “bells  and  whistles” 
requiring  the  user  to  have  fast  modems  or  suffer  extreme  download  times.  These  issues 
will  be  more  thoroughly  explored  in  Chapter  VI,  discussion  of  the  actiml  Intranet 
prototype.  Also,  the  Intranet  would  act  as  a  template  to  ensure  standardization,  and 
should  be  accompanied  with  recommendations  as  to  content  control  policy  and  successful 
use,  as  discussed  in  Chapter  VII.  Lastly,  it  was  decided  that  the  prototype  would  be 
designed  with,  and  would  need  to  be  used  in  conjunction  with,  the  Microsoft  Office 
family  of  applications,  already  the  standard  at  the  division.  This  W2is  done  both  to  ensure 
the  ultimate  portability  of  the  prototype,  to  address  compatibility  with  local  division 
information  systems  already  developed,  and  to  take  advantage  of  a  preexisting  level  of 
expertise  in  use  of  these  tools. 

Next,  the  initial  requirements  meeting  addressed  narrowing  the  number  and  kinds 
of  functions  to  be  built  into  the  prototype  Intranet  once  designed  and  developed.  The  first 
of  these  functions  would  be  a  personnel  database  to  augment  the  SIDPERS  database  and 
provide  more  flexibility  in  reporting  and  data  mining.  The  context  level  Data  Flow 
Diagram  (DFD)  in  Figure  5.1  illustrates  the  current  system  for  retrieving  information 
from  the  SIDPERS  database.  It  should  be  noted  that  the  major  inefficiencies  here  are 
twofold. 
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Query  results 


Figure  5.1.  SIDPERS  Procedures 


Figure  5.2  shows  that  the  process  of  submitting  changes  to  the  SIDPERS  database 
is  extremely  cmnbersome,  sometimes  involving  providing  a  faster  and  more  simplified 
process  for  making  inquiries  and  providing  a  more  up  to  date  database  from  which  to 
inquire  and  reconcile  against  the  SIDPERS  database.  The  team  was  to  make  no  effort  to 
link  this  concept  vehicle  to  the  actual  SIDPERS  database. 
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Figure  5.2.  Level  Zero  Diagram  of  SIDPERS  Procedure 


It  was  also  requested  that  the  team  look  at  simplifying  procedures  reqmred  to 
capture  a  unit’s  readiness  posture  via  the  Unit  Status  Report  (USR).  This  report  consists 
of  over  thirty  pages  and  is  currently  handled  as  depicted  in  Figure  5.3.  The  reader  should 
note  that  at  least  one  representative  from  each  battalion,  separate  battalion  and  company, 
and  subsequent  higher  commands  would  be  needed  to  participate  in  the  effort  described 
in  the  figure,  totaling  at  least  42  people.  It  was  this  mass  of  administrative  effort, 
information  distribution  and  travel,  for  face  to  face  coordination,  the  team  was  to  address. 
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Figure  5.3.  Context  Level  Diagram  of  USR  Procedures 
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Figure  5.4.  Level  Zero  Diagram  of  USR  Procedure 


Similarly,  commanders  at  all  levels  often  require  a  personnel  status  report,  either 
as  part  of  the  USR  performed  each  quarter,  or  to  manage  his/her  personnel  strengths. 
Figure  5.5  depicts  the  effort  a  typical  battalion  exerts  in  collecting  and  posting  this 
information.  It  should  be  remembered  that,  because  the  sponsor  is  a  reserve  military 
organization,  these  activities  are  occurring  at  various  homes  throughout  the  month 
involved.  Accordingly,  the  action  required  from  the  team  was  to  identify  those  items  of 
information  most  often  needed  and  create  an  interactive  environment  wherein  the 
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company  commanders  could  readily  ascertain  the  information  requirements,  annotate 
only  that  information  which  has  changed,  and  return  the  information  in  a  standardized 
format  for  rapid  inclusion. 


FORMATS  (X5) 


Figure  5. 5.  Level  Zero  Diagram  of  Personnel  Status 


The  final  requirement  identified  during  the  first  trip  and  reported  in  Appendix  A 
involves  sharing  information  about  major  training  activities  and  events  at  each  layer  of 
command.  Currently,  commands  use  a  variety  of  scheduling  tools  such  as  Microsoft 
Organizer,  Calendar  Creator  Plus,  and  assorted  word  processors  to  record  and  distribute 
information  about  planned  activities.  This  information  is  then  physically  passed  to  those 
personnel  identified  by  the  creator  as  needing  the  information.  Anyone  outside  the 
normal  distribution  chain  who  could  make  use  of  the  information  either  must  request  it, 
or  is  ignorant  of  its  existence.  The  requirement,  then,  was  to  develop  a  standardized 
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static  environment  that  would  be  expected,  could  be  used  throughout  the  chain  of 
command,  and  could  be  easily  referenced  by  anyone  with  access  to  the  Intranet. 

These  base  functions  are  further  reviewed  in  detail  in  Appendix  C,  with 
discussion  by  function  for  the  following  areas: 

•  Entities  affected 

•  Number  of  users 

•  Primary  owners 

•  Frequency  of  use 

•  Mode  of  use 

•  Type  and  source  of  information 

•  Miscellaneous  information 

Appendix  B  is  a  trip  report,  which  records  the  events  of  a  second  meeting  with  the 
project  sponsor.  There  was  a  dual  purpose  to  this  trip.  First,  the  prototype  developed 
since  the  first  meeting  was  demonstrated  to  determine  that  the  skeleton  design  and 
functions  built  to  represent  the  needs  identified  above  were  on  target.  Next,  a  structured 
walkthrough  was  to  be  performed  with  each  of  the  organization’s  key  staff  members  to 
identify  any  additional  requirements.  These  requirements  would  ensure  that  the 
prototype  meets  the  nucleus  needs,  a  must  for  the  Intranet  to  succeed. 

As  to  the  results  of  the  former,  the  demonstration  to  the  key  sponsor  of  the 
skeleton  design  and  key  functions  indicated  that  these  efforts  were  on  the  mark.  The 
sponsor  gave  the  approval  to  proceed  with  development  of  the  Intranet  exactly  as 
prototyped.  While  the  latter  activity  identified  no  new  nucleus  requirements,  a  number  of 
“nice  to  have”  requirements  emerged.  Since  it  was  deemed  important  that  the  key  staff 
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involved  in  this  process  support  the  concept  of  an  Intranet  if  the  scheme  were  to  succeed, 
as  many  of  these  functions  were  incorporated  as  time  allowed.  The  requirements  for 
those  functions  incorporated  are  discussed  below. 

Overall,  it  was  agreed  that  the  biography  template  (complete  with  digital  image) 
was  viable  for  the  Commanding  General,  Assistant  Commander  (Maneuver),  Assistant 
Commander  (Support)  and  the  Sergeant  Major.  Subsequent  layers  of  command  would 
contain  biographies  for  the  Commander,  Executive  officer  and  Sergeant  Major. 

The  officers  and  non-commissioned  officers  of  the  personnel  and  administration 
section,  the  G-1,  determined  that  a  requirement  for  a  directory  of  staff  officers  and  senior 
non-commissioned  officers  with  phone  numbers  and  addresses  existed.  These  directories 
are  traditionally  maintained  and  distributed  in  paper  format,  and  are  very  difficult  to  keep 
up  to  date.  Often,  the  paper  copy  is  not  present  when  needed,  and  reduced  copies  are 
often  carried. 

Another  problem  often  faced  by  G-l/S-1  is  locating  and  copying  the  many 
standard  forms  used  by  the  Army.  The  need  existed  for  a  centralized  repository  of 
downloadable  electronic  versions  of  these  standard  forms,  and  the  potential  existed  for 
use  of  the  Army  standard  form  generator.  Form  Flow  by  Delrina. 

Finally,  the  G-1  identified  the  need  for  a  report  matrix,  which  would  contain  a  list 
of  required  reports,  indications  of  who  was  responsible  for  submittal,  and  when  the  report 
was  due.  It  was  generally  agreed  that  these  “suspense”  pages  would  be  a  usable  tool  for 
each  staff  section,  and  would  be  added  to  each  section's  content. 

The  intelligence  personnel  of  the  G-2  identified  a  unique  need.  These  personnel 
are  involved  in  a  process  of  continually  updating  and  distributing  an  unclassified  threat 
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brief  for  subordinate  unit  intelligence  personnel  and  conunanders.  By  nature,  these 
reports  will  be  out  of  date  before  the  recipients  can  obtain  and  read  them.  The  team’s 
objective  was  to  create  a  readily  updateable  vehicle  for  conveying  these  reports. 

The  G-2  further  identified  a  problem  that  many  staff  officers  share.  As  the 
Division  Intelligence  Officer,  Division  Logistics  Officer,  Division  Personnel  Officer,  etc., 
these  staff  officers  represent  their  occupational  skill  as  the  senior  member  in  the 
organi2ation.  As  such,  it  is  incumbent  on  them  to  monitor  staffing  levels  within  the 
division  for  those  personnel  in  their  field  in  order  to  balance  deficiencies  and  overages 
between  units,  and  to  notify  the  commander  and  Army  manpower  agencies  when  major 
deficiencies  are  identified.  Accordingly,  it  was  requested  that  the  team  develop  a  means 
for  these  managers  to  conduct  a  query  and  receive  data  on  the  present  and  future 
population  of  any  given  Military  Occupational  Specialty. 

The  operations  staff  in  the  G-3  had  several  fimctions  to  be  added  to  the  Intranet 
prototype.  Perhaps  the  most  important  of  the  functions  was  the  event  calendar  identified 
earlier.  The  G-3  usually  maintains  an  event  calendar  showing  major  training  events.  A 
related  function  is  provided  by  the  Standard  Army  Training  System  Version  4.0.  This 
CD  delivered  product  provides  both  scheduling  tools  and  standard  training  and  training 
requirements  reports  and  forms.  It  was  requested  that  the  team  research  this  tool  and 
discern  what  level  of  interaction  with  this  system  the  prototype  could  achieve. 

Another  derivation  on  an  earlier  identified  need  was  an  action  oriented  suspense 
page,  as  opposed  to  an  administrative  report  suspense  page.  The  Logistics  officials  in  the 
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G-4  also  desired  an  action-oriented  page.  The  team’s  task  w£is  to  develop  a  template 
page  wherein  required  actions  and  updates  on  event  planning  could  be  posted  for  all  to 
share. 

Figure  5.6  illustrates  a  coordinating  procedure  known  among  the  reserve  officers 
as  “Dark  Night”.  The  concept  behind  this  procedure  is  that  planning  documents  for 
upcoming  drill  weekends  are  distributed  for  review  and  key  members  from  staffs  up  and 
down  the  chain  of  command  travel  to  a  central  location  on  the  Thursday  prior  to  a  drill  to 
coordinate  required  actions  and  the  review  plans.  These  officers  then  travel  back  to  their 
homes,  work  Fridays  and  travel  once  again  to  their  unit  for  weekend  drill.  The  reader 
should  note  that  both  the  cost  of  distribution  of  plans  and  travel  for  coordination  are 
normally  absorbed  by  the  individual  officer.  There  is  a  clear  requirement,  then,  for  a 
method  of  distributing  and  discussing  drill  plans  before  a  weekend  which  lessens  the  time 
and  cost  to  the  officers. 

In  addition  to  the  event  page  described  above,  the  G-4  also  identified  the 
requirement  to  provide  a  viable  means  for  requesting  supplies  and  services  in  a  fashion 
which  ensures  approval  from  the  logistics  shop  at  the  subordinate  command.  The 
sponsor  identified  the  need  to  specify  procedures  for  determining  requirements  and 
ordering  supplies  by  their  class  of  supply  (I-X).  Further,  several  local  forms  used  to 
request  such  services  as  bus  support  or  convoy  permissions  have  been  developed  and  are 
currently  handled  in  paper  format.  The  Intranet  was  seen  as  a  good  vehicle  for 
distribution  of  these  forms  and  providing  a  means  for  submittal  of  requests. 
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REVIEWED  PLANS 


Relations  v^th  the  organization  have  also  identified  the  requirement  for  the  team 
to  provide  recommendations  on  content  quality  and  control.  It  is  recognized  that  since 
the  Intranet  is  to  reside  on  government  owned  equipment  and  be  available  to  government 
employees,  the  system  content  should  be  in  accordance  with  both  societal  norms  and 
current  regulations.  A  thorough  identification  of  Army  and  DOD  requirements  and 
valuable  content  control  measures  from  civilian  organizations  is  needed. 

As  mentioned  in  Chapter  IV,  these  ongoing  relations  have  also  identified  the  need 
for  the  team  to  provide  recommendations  on  potential  security  directions  that  the  division 
should  consider. 
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E.  CONCLUSION 


This  chapter  sought  to  acquaint  the  reader  with  the  most  plausible  of  the 
division’s  requirements,  as  determined  by  the  Intranet  team’s  ability  to  provide  solutions. 
The  requirements  were  broken  between  the  essential  design,  some  priority  functions  and 
some  nice  to  have  additions  designed  to  ensure  support  by  those  key  staff  sections  whose 
participation  is  needed  if  the  Intranet  is  to  succeed.  While  implementation  of  the  basic 
design,  key  requirements  and  nice  to  have  items  will  be  discussed  at  length  in  the 
forthcoming  chapter  on  protot3T>e  implementation,  the  last  two  considerations  involving 
recommendations  on  security  measures  and  content  control  procedures  will  not  be 
addressed  again  until  Chapter  VII. 
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VI.  THE  PROTOTYPE 


A.  INTRODUCTION 

The  goal  of  this  chapter  is  to  walk  the  reader  through  the  prototype  development 
process  actually  followed  in  creating  this  Intranet  prototype,  and  explain  the  design  and 
functionality  evolution  that  transpired  along  the  way. 

B.  DEVELOPING  A  WORKING  PROTOTYPE 

Following  the  prototyping  process  defined  in  Chapter  IV  and  represented  in 
Figure  4.2,  the  first  step  in  prototype  development  is  a  very  rapid  determination  of  the 
user’s  basic  requirements.  Chapter  V  discussed  the  gathering  and  definition  of  these 
initial  requirements.  The  team's  goal  in  developing  the  “first  cut”  prototype  was  to 
provide  a  very  limited,  rapidly  produced  set  of  Intranet  pages  incorporating  the  major 
functions  to  simultaneously  validate  and  verify  the  initial  direction  of  the  project.  The 
below  paragraphs  describe  and  exhibit  the  efforts  made  in  developing  this  first  cut 
prototype. 

The  first  requirement  to  be  addressed  was,  by  necessity,  the  basic  design  of  the 
Intranet,  the  cornerstone  of  the  project  as  a  whole.  The  primary  consideration  here  was 
that  a  division  viewpoint  should  be  used  to  gmde  the  design  development.  The  reader 
may  remember  that  Figure  3.1  shows  the  structure  of  the  40*  Infantry  Division  first 
introduced  in  Chapter  III.  The  average  military  member  is  fairly  conversant  with  this 
structure  and  most  activities  are  controlled  using  personnel  along  this  chain  of  command 
in  a  hierarchical  manner.  As  a  consequence,  the  team  believed  that  this  design,  which 
followed  the  organization's  structure,  would  be  the  most  intuitive  way  for  users  to 
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navigate  the  web.  Figure  6.1  shows  the  structure  of  the  Intranet.  This  “screen  shot” 
represents  what  will  be  called  the  left  frame.  It  is  this  frame  which  becomes  the  vehicle 


Figure  6.1.  Left  Frame  Layout 


for  navigating  the  Intranet  via  the  command  structure.  Note  that  only  the  major 
conunands  are  listed  on  this  page. 

Figure  6.2  shows  the  structure  of  the  right  frame  the  user  encounters  upon 
selecting  a  unit  from  the  left  frame.  As  can  be  seen  by  the  concentric  layering,  this  frame 
provides  the  method  for  navigating  at  any  given  level  of  command.  Each  level  contains 
links  to  both  staff  sections  and  subordinate  commands.  It  is  also  in  this  frame  that  the 
links  to  the  required  fimctions  identified  in  Chapter  V  will  exist. 
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Figure  6.2.  Right  Frame  Layout 
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Figiore  6.3  provides  a  view  of  the  initial  frames  as  seen  from  a  browser. 


Figure  6.3.  Opening  Screen 

Figure  6.4  demonstrates  the  change  the  user  would  witness  to  the  right  frame  if 
selecting  the  G-4  link  in  Figure  6.3.  The  reader  should  note  that  the  functions  identified 
for  the  G-4  in  Chapter  V  are  represented  as  links  in  the  new  matrix.  It  should  also  be 
noted  that  the  left  frame  is  never  changing,  providing  the  user  with  a  means  of  easily 
moving  from  one  major  command  to  the  next,  and  always  returning  to  the  “home  page” 
represented  by  the  upper  level  Division  page  seen  in  Figure  6.3. 


Figure  6.4.  G-4  Selected 

Figure  6.5  displays  the  right  frame  presented  when  the  user  selects  the  1®‘  Brigade 
from  the  left  frame.  Attention  is  directed  to  the  similar  structure  of  the  right  frame 
between  the  commands.  Even  though  subordinate  umts  have  now  appeared  in  the  matrix, 
the  overall  format  remains  the  same  to  improve  intuitive  browsing  by  the  user.  Note  also 
that  the  staff  sections  are  represented,  but  now  show  the  “S”  designation  vice  the  G 
designation  used  at  the  division  level. 

Another  primary  design  consideration  is  the  speed  with  which  the  system  will 
respond.  Efforts  to  ensme  a  rapid  response  of  the  system  included  simplicity  and 
standardization  of  color,  number  of  page  formats  and  page  design.  Since  the  left  frame 
never  changes,  this  page  is  always  cached  on  the  user's  computer  after  initial  download. 
Similarly,  the  background  for  the  right  frame  (at  any  level  of  command)  is  composed  of  a 
single  picture  of  brown  “spray  paint”  speckles  designed  to  load  quickly.  There  are  only 


Figure  6.5.  1**  Brigade  Home  Page 

two  other  backgrounds  used  in  the  right  frame  of  the  Intranet.  Once  below  the  staff  level 
at  any  command,  the  user  encounters  a  white  backgroimd  with  a  watermarked  U.S.  Army 
insignia.  Below  this  level  is  a  white  background  with  a  watermarked  40*  Division 
insignia.  Again,  once  downloaded,  these  pictures  are  cached,  and  will  quickly  return 
upon  change  of  levels.  Page  design  was  kept  simple,  with  the  same,  quick  loading 
delimiting  lines  and  standardized  artwork  throughout  all  layers  of  the  Intranet.  Sounds, 
video  streaming  and  other  time  and  space  consuming  features  were  avoided. 

The  next  requirement  addressed  was  the  personnel  database.  What  the  team  heard 
initially  from  the  project  sponsor,  in  reference  to  tracking  personnel  information,  was  that 
the  information  provided  by  the  state’s  SIDPERS  database  is  outdated  and  does  not 
provide  a  timely  and  accurate  reflection  of  the  personnel  status  in  the  division.  Another 


complaint  about  the  SIDPERS  system  was  the  limited  access  and  limited  querying 
capability.  The  scope  of  the  project  prevented  attempting  changes  of  a  large  legacy 
system  such  as  the  SIDPERS  system.  Rather,  it  was  our  intent  to  show  the  division  the 
dynamic  flmctionality  available  which,  with  further  analysis,  could  set  the  stage  for  the 
development  of  a  full-blown  web-based  internal  (within  the  division)  personnel  database 
management  system.  The  personnel  management  system  should  be  developed  so  that  it 
can  work  in  concert  with  the  legacy  SIDPERS  system  and  focus  on  overcoming  its 
shortfalls  (i.e.,  no  timely  data  updates,  limited  access,  limited  querying  capability). 
Ideally,  the  two  systems  would  interact  so  that  data  could  be  shared.  Which  personnel 
information  fields  to  track  and  place  in  the  dynamic  database  was  determined  by  studying 
a  stand-alone  database  put  together  by  the  240*  Signal  Battalion.  The  developed 
prototype  consists  of  two  input  forms  which  contain  sixty-eight  fields  of  personnel 
related  information.  One  of  the  two  input  forms  is  pictured  in  Figure  6.6. 


Figure  6.6.  Data  Entry  Screen 
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We  demonstrated  to  our  sponsor  the  ability  to  store  and  retrieve  database  records 
using  the  input  screens  put  together  for  the  initial  demonstration.  It  was  agreed  that 
further  development  in  this  area  would  focus  on  the  SIDPERS  shortfall  areas  (i.e.,  query 
capability,  accessibility,  data  timeliness  and  accuracy,  etc.). 

The  requirement  for  a  local  personnel  status  reporting  form  was  fully  addressed 
before  the  next  meeting.  A  spreadsheet  solution  already  used  by  division  (See  Figure 
6.7)  proved  to  be  the  answer.  Another  spreadsheet  solution  was  available  from  the  240* 
Signal  Battalion.  While  both  solutions  were  included  in  the  prototype,  further 
discussions  as  to  the  solution  will  refer  to  the  division  model.  This  spreadsheet  can  be 
adapted  to  work  at  any  level  of  command.  The  team  took  advantage  of  “working 
together”  inherent  in  using  all  Microsoft  Office  compatible  tools,  and  linked  the  report  to 
the  G-1 /Personnel  page.  Once  linked  and  selected  by  the  user,  this  file  will  regenerate  on 
any  computer  having  Microsoft  Excel.  For  those  who  do  not  desire  to  load  Office 
products  or  other  executable  suites  on  their  Personal  Computers,  the  webmaster  can  make 
available  downloadable  viewers  for  various  products,  or  direct  the  user  to  the  company's 
web  page  on  the  internet,  where  viewers  are  almost  universally  available  for  download. 

If  the  user  desires  to  make  changes  to  the  Excel  file  and  return  it  to  the  Battalion  (via  E- 
mail  attachment  or  FTP),  an  executable  version  of  Excel  or  Excel  compliant  spreadsheet 
must  be  resident  on  their  PC. 
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Figure  6.7.  Personnel  Master  Report  Spreadsheet 


This  function  met  with  approval  as  displayed,  and  no  further  revision  was 
necessary. 

Figure  6.8  provides  a  view  of  a  basic  weekend  timeline  saved  in  HTML  format 
from  Microsoft  Schedule  Plus.  This  schedule  was  prepared  as  an  example  of  what  may 
be  done  in  the  field  of  event  scheduling.  The  reaction  to  this  schedule  and  the  other 
functions  discussed  above  will  be  the  subject  of  the  next  section. 
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Figure  6.8.  Microsoft  Schedule  in  HTML 


C.  INTERMEDIATE  STEPS 

1.  Demonstration  of  the  Prototype  and  User  Satisfaction 

As  brought  out  in  Chapter  V,  a  structured  walkthrough  was  conducted  with  both 

the  sponsor,  and  members  of  the  division’s  primary  staff.  This  step  provided  the 
following  results: 

•  The  basic  design  was  considered  satisfactory,  and  the  team  was  requested  to 
continue  filling  out  the  “skeleton”. 

•  The  command  was  very  pleased  with  the  concept  demonstrated  by  the  Active 
Server  Page  —  Database  combination,  and  desired  a  continuation  along  this 
path,  providing  some  further  guidance  as  to  desired  functions,  to  include  the 
MOS  search  identified  by  the  G-2. 

•  The  Personnel  Status  Report  was  blessed  “as  is”,  and  the  team  determined  to 
spend  no  more  effort  on  this  tool. 
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•  The  training  schedule  example  served  its  purpose  as  a  vehicle  for  generating 
follow-on  requirements.  ’V^le  some  pmposes  could  be  served  by  the 
daily/hourly  format  afforded  by  the  Microsoft  Schedule  Plus  format,  the  more 
universally  used  Calendar  Creator  Plus  format  was  desired.  The  “event  box” 
feature  allowing  a  multi-day  view  of  a  single  event  ensured  that  Calendar 
Creator  had  become  the  de  facto  division  standard. 

•  At  the  time  of  the  structured  walkthrough,  not  enough  information  about  the 
Unit  Status  Reporting  procedures  had  been  gathered  to  include  this  function  in 
the  initial  prototype. 

2.  Gather  Follow-on  Requirements 

At  the  second  meeting  with  the  project  sponsor,  the  prototype  walkthrough  was 
repeatedly  conducted  with  each  of  the  senior  officers  and  staff  non-commissioned 
officers  from  each  of  the  sections.  As  stated  in  Chapter  V,  the  purpose  of  this  activity 
was  to  gather  additional  requirements  for  follow-on  inclusion  in  the  prototype.  These 
requirements  took  shape  both  in  the  form  of  those  identified  for  the  basic  functions 
above,  and  also  the  “nice  to  have”  items  which  would  help  increase  support  of  the  project 
within  the  division.  The  additional  liaison  with  the  organization  also  helped  to  provide 
more  information  on  and  better  substantiate  the  requirements  for  the  USR  task.  While 
Chapter  V  has  already  covered  these  requirements  in  adequate  detail,  the  next  section  will 
describe  how  the  development  team  met  these  needs. 

B.  ENHANCEMENTS  TO  THE  PROTOTYPE 

The  discussion  on  the  revision  of  the  prototype  model  begins  with  the  interactive 
personnel  database.  The  utility  in  having  an  accessible  database  in  a  web  environment  is 
that  those  authorized  access  can  use  it  as  a  decision  support  tool  by  way  of  useful  queries. 
Microsoft  Access  provides  the  capability  to  save  queries  and  forms  in  HTML  format. 
Active  Server  Pages  created  by  Microsoft  are  HTML  pages  which  are  created  by  the 
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Figure  6.9.  MS  Access  Switchboard 


server  “on  the  fly”  or  dynamically.  Figure  6.9  depicts  an  MS  Access  generated 
switchboard.  Access  97  allows  you  to  save  forms  and  queries  in  HTML  format  and 
provides  a  convenient  way  to  access  them  via  switchboard  that  contains  links  to  the 
desired  form  or  query.  Figure  6.10  shows  the  results  of  a  query  for  all  soldiers  in  the 
grade  greater  than  (>)  or  equal  to  (=)  E-7.  This  HTML  results  page  was  dynamically 
generated  by  the  server  software  and  sent  to  the  client  browser.  An  endless  number  of 
queries  can  be  generated  using  any  number  of  the  68  data  fields  and  posted  to  the 
switchboard.  As  can  be  seen  on  the  switchboard  in  Figure  6.9,  a  Military  Occupational 
Specialty  (MOS)  query  was  developed  in  the  prototype  which  allows  users  to  query  for 
particular  MOS,  a  requirement  discussed  previously. 


E-7  Carter _ M  11B  Bco  2-160  Inf 

E-7  Beriy _ F _ 71 L  HHC  4Qth  Inf  Div 

E-7  McNamara _ M _ 19K  1-1 49th  Armor 

E-8  Howard  M  31 C  Cco  240th  Si  ana 


Figure  6.11.  Connection  to  USR  Templates 
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The  USR  requirement  was  solved  in  a  maimer  very  similar  to  the  Personnel  Status 
Report  effort.  The  3 1 -page  report  was  found  in  a  format  that  could  be  saved  as  a 
Microsoft  Word  template  and  saved  in  the  web  as  a  file.  Figure  6.1 1  displays  the  link 
between  the  G-3  shop’s  web  page  and  the  file.  When  the  user  selects  this  link,  the  file  is 
downloaded  and  can  be  saved  or  manipulated,  then  E-mailed  back.  Further,  once 
downloaded,  these  files  can  be  viewed  and  manipulated  within  a  teleconferencing  tool 
that  will  be  described  in  greater  detail  in  the  Dark  Night  paragraph  below.  By  using  these 
methods,  the  42  plus  unit  representatives  can  be  spared  the  time  and  expense  of  physical 
file  transfer  and  face  to  face  coordination  (represented  in  Figure  5.4)  currently  taking 
place  each  quarter. 


_  _ _ 
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Figure  6.12  displays  the  actual  sample  page  created  to  answer  the  problem  of  a 
standardized  event  calendar.  Contact  with  the  Soft  Key  Corporation,  makers  of  Calendar 
Creator  Plus  (CCPlus),  indicated  that  no  effort  was  currently  being  expended  toward 
making  an  HTML  version  of  their  product.  Since  CCPlus  was  clearly  the  tool  of  choice 
among  the  division’s  planners,  a  method  of  posting  the  calendars  already  being  created 
appeared  to  be  the  most  viable  solution.  Accordingly,  the  team  created  an  index  based 
web  page  with  the  standardized  background  and  look.  The  user  first  encounters  the  top 
of  the  page,  which  shows  date  blocks  for  that  level  of  command’s  calendars.  When  a 
date  is  selected,  the  page  advances  to  that  portion  with  the  CCPlus  calendar  pasted 
directly  to  that  section,  as  shown  in  the  Figure.  Using  this  template  page,  units  up  and 
down  the  chain  of  command  may  now  post  their  training  and  event  planning  calendars  on 
their  unit’s  web.  These  planning  tools  will  then  be  available  for  absorption  by  members 
of  the  command,  and  for  coordination  with  higher  level  and  adjacent  commands. 

Of  the  additional  functions  requested  by  various  staff  sections,  one  of  the  most 
useful  was  a  directory  model  that  could  be  used  at  each  level  of  command  to  keep  up  to 
date  points  of  contact.  The  template  represented  in  Figure  6.13  is  also  based  on  an  index 
web  page  design.  When  a  letter  is  selected,  the  browser  proceeds  to  that  portion  of  the 
page  and  the  data  is  presented.  Since  the  data  is  cross-referenced  by  name  and  billet, 
either  an  individual  or  all  persons  in  a  particular  section  can  be  displayed.  Moreover,  a 
web  connection  to  that  person’s  E-mail  address  can  be  installed.  When  selected,  this 
connection  will  launch  the  user’s  default  mail  program,  enabling  immediate  message 
writing  capabilities.  Additional  useful  information  has  been  appended  to  the  end  of  the 
directory.  These  include  a  listing  of  all  E-mail  account  holders  and  a  listing  of  all  unit 
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addresses  and  duty  telephone  numbers.  This  template  could  easily  be  used  in  conjunction 
with  a  password-protected  web  structure  to  provide  home  addresses,  phone  numbers  and 
“social  rosters”  often  tightly  controlled  in  paper  form.  If  each  layer  of  command  were  to 
copy  and  maintain  this  directory,  a  very  up  to  date  point  of  contact  hierarchy  could  be 
easily  laid  out,  with  links  from  a  central  page  at  the  division  level  to  subsequent  layers  of 
command. 


Figure  6.13.  Division  Directory  Page 

To  facilitate  use  of  the  directory,  the  team  also  decided  to  add  a  search  engine 

function  on  the  division’s  home  page.  By  typing  a  name,  billet  or  function  into  the  query 
block,  all  the  pages  contained  within  that  web  will  be  searched  for  mention  of  the 


78 


requested  “term”,  and  return  a  matrix  of  connections  which  provide  links  to  the  pages  on 
which  the  term  can  be  foimd. 

While  it  might  prove  possible  to  run  the  Form  Flow  executable  program  from  the 
network  server,  running  it  within  the  prototype  was  infeasible.  However,  the  team  did 
have  some  success  in  dealing  with  this  application.  By  saving  the  files  for  each  of  the 
forms  in  the  format  used  by  Delrina’s  Form  Flow,  then  storing  them  within  the  web,  a 
link  to  each  form  could  be  made.  Like  many  of  the  applications  identified  above,  any  PC 
with  the  Form  Flow  executable  file  could  download  and  manipulate  the  files.  This  setup 
allows  the  client  PC  to  be  as  thin  as  possible,  alleviating  the  need  for  storing  seldom  used 
formats,  and  allowing  access  even  when  traveling. 

The  next  function  the  team  addressed  involved  the  Required  Reports  page 
identified  as  essential  by  the  G-1.  Figure  6.14  depicts  the  page  developed  to  handle  this 
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Figure  6.14.  Portion  of  G-1  Required  Report  Page 

need.  A  table  generator  was  used  to  create  a  matrix  with  required  reports  along  one  axis 
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and  dates  along  the  other.  Codes  were  used  to  indicate  who  was  responsible  for  report 
submittal.  It  should  be  pointed  out  that  if  the  report  is  in  a  standardized  local  format,  a 
link  to  that  form  could  easily  be  established,  using  the  block  containing  the  report  name 
as  the  launch  point  on  the  page.  Further,  if  the  need  exists  to  archive  any  given  report,  an 
interactive  database  similar  to  the  personnel  database  could  be  set  up  to  retrieve  data  from 
the  users  and  store  it  appropriately.  As  mentioned  in  Chapter  V,  these  suspense  pages 
were  provided  in  each  of  the  staff  section’s  webs,  and  a  template  provided  for  use  at 
lower  levels. 

The  solution  suggested  to  tackle  the  G-2’s  continuous  need  for  publishing 
unclassified  threat  and  country  briefs  was  the  corporate  newsletter.  As  seen  in  Figure 


Figure  6.15.  Intelligence  Newsletter 
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6.15,  a  G-2  newsletter  was  created  and  saved  in  HTML  format.  Using  an  HTML  editor, 
the  G-2  authorized  representative  can  easily  update  text,  photos  and  links  to  other  sites 
such  as  maps,  better  addressing  the  perishability  of  information  issues,  and  reducing  time 
and  dollar  costs  associated  with  updating  and  redistribution.  Similar  sites  could  be 
established  for  fictional  threats  during  staff  planning  exercises.  Password  protected 
versions  may  prove  to  be  an  acceptable  means  of  communicating  higher  classification 
briefs. 

Like  the  Form  Flow  forms  generator,  the  Standard  Army  Training  System  (SATS) 
executable  could  not  be  run  from  within  the  Web.  However,  the  program  CD  contained 
the  system’s  numerous  required  report  formats  saved  as  Microsoft  Word  templates.  By 
saving  these  to  the  web  and  creating  links  for  the  reports,  the  SATS  program  could  be 
bypassed  and  the  user  could  open  these  formats  directly  with  Word,  then  mampulate  and 
submit  them  electronically. 

One  of  the  functions  requested  by  the  G-3  is  expected  to  become  a  widely 
accepted  change  in  current  procedures.  This  function  is  the  Dark  Night  event-planning 
page.  As  discussed  in  Chapter  V,  a  large  number  of  officers  from  all  levels  of  command 
are  required  to  expend  massive  time  and  energy  conducting  coordination  prior  to  any  drill 
period.  The  commander’s  letter,  depicted  in  Figure  6.16,  contains  guidance  and  planning 
documents  generated  by  the  key  staff  and  commander  of  a  unit.  The  individual  officer 
within  a  unit  can  then  browse  the  pages  prior  to  coordination.  Next,  the  commander  and 
his  staff  may  coordinate  either  at  will  or  at  a  pre-designated  time  using  teleconferencing 
tools. 
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Figure  6.16.  Sample  Dark  Night  Page 

The  tool  designed  to  be  run  with  FrontPage  and  IIS  is  a  free  download  program 
from  Microsoft,  and  is  available  at  the  microsoft.com  Internet  site.  Figure  6.17  is  a 
screen  shot  depicting  this  tool  in  use.  In  addition  to  standard  chat  and  whiteboard 
functions,  this  tool  allows  document  sharing,  document  collaboration  (i.e.,  shared 
revising),  audio  and  video.  Once  a  document  is  tagged  by  a  conference,  the  document 
may  be  revised  by  anyone  assuming  control,  using  the  executable  from  the  PC  of  the 
person  who  posted  it.  The  audio  is  very  usable  for  discussing  changes  as  they  are  made. 
The  video  could  be  useful,  but  will  slow  response  time  of  other  features.  As  mentioned 
above,  this  tool  is  a  good  alternative  to  traveling  for  coordination  purposes,  and  can  be 
used  for  other  event  planning  and  collaboration  needs.  Additionally,  the  tool  should 
prove  very  beneficial  in  USR  report  validation/verification,  relieving  the  unit 
representative  from  having  to  travel. 
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Figure  6.17.  NetMeeting 


Similar  event  planning  pages  were  created  for  the  G-4,  which  should  prove  useful 
whether  used  in  conjimction  with  NetMeeting,  or  used  solely  as  an  information  tool. 
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Since  both  the  G-3  and  G-4  are  heavily  involved  in  event  planning  and  control, 
the  standard  report  matrix  used  throughout  the  rest  of  the  staff  was  modified  to  include 
action  items.  Figure  6.18  provides  an  example  of  this  type  of  suspense  page.  Again, 
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Figure  6.18.  Report/Action  Suspense  Page 


codes  may  be  used  to  provide  information  beyond  the  action  item,  and  the  suspense  dates. 
Room  for  a  legend  is  provided  at  the  bottom  of  the  web  page. 
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Figure  6.19  presents  the  G-4  homepage.  The  reader’s  attention  is  drawn  to  the 
table  in  the  center  of  the  page.  While  suspense  and  event  planning  pages  have  already 
been  discussed,  the  table  also  provides  the  user  the  opportunity  to  link  to  pages 
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Figure  6.19.  G-4  Home  Page 

concerning  various  classes  of  supply.  These  pages  can  contain  information  about  how  to 
order  the  supplies,  who  will  be  charged,  and  planning  considerations.  The  other  major 
link  from  the  table  is  to  the  support  requests  page.  On  this  page,  the  user  will  find  a  list 
of  links  to  individual  support  request  forms  that  have  been  in  local  use  for  some  time. 
The  prototype  team  converted  these  forms  into  Microsoft  Word  templates  and  stored 
them  in  the  G-4  folder  of  the  Intranet.  Figure  6.20  displays  how  selecting  one  of  these 
forms  causes  Word  to  be  laxmched  on  the  user's  PC,  immediately  opening  the  required 
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form  for  use.  This  form  can  then  be  E-mailed  back  to  the  G-4  for  action.  While  an 
interactive  database  solution  could  also  have  been  applied,  the  G-4  felt  the  E-mail  step 
provided  them  the  means  to  authenticate  that  the  person  making  the  request  indeed  had 
the  power  to  do  so,  as  the  return  address  would  identify  them  as  a  key  billet  holder. 


Figure  6.20.  Convoy  Request  Opened  Within  Browser 

Lastly,  the  overall  design  was  finalized.  Templates  were  made  of  home  pages, 
biographies,  suspense  pages,  etc.  These  pages  were  then  duplicated  at  the  division  level 
as  appropriate  and  a  link  to  these  templates  was  created  on  the  left  frame  so  that 
subordinate  units  could  gain  access  as  they  filled  out  the  skeleton  structure  already 
provided  them. 


E.  OPERATIONAL  PROTOTYPE 


Once  the  above  action  was  complete,  a  second  structured  walkthrough  was 
conducted  and  the  protot3^e  was  accepted.  As  discussed  in  Chapter  IV,  this  action 
marked  the  passing  from  the  initial  prototype  to  the  operating  prototype  phase  of  the 
prototype  life  cycle.  Chapter  IV  also  introduced  the  concept  that,  unlike  traditional 
software  development.  Intranet  content  is  constantly  evolving.  It  can  be  seen,  therefore, 
that  this  phase  represents  more  than  a  transition  to  an  operation  phase,  but  instead 
represents  a  transition  from  the  prototype  development  process  to  the  end-user 
development  process. 

F.  CONCLUSION 

The  prototype  development  process  defined  in  Figure  4.2  was  followed  in 
developing  this  Intranet.  This  method  was  used  both  because  of  the  rapid  time  frame  the 
sponsor  desired  to  work  within,  and  because  of  the  somewhat  ill  defined  requirements.  In 
this  instance,  the  ability  to  provide  a  structured  walkthrough  not  only  ensured  an  adequate 
design,  but  also  really  helped  to  identify  the  potential  the  Intranet  technology  could 
provide  for  this  unit.  The  goal  of  this  chapter  was  to  walk  the  reader  through  the 
prototype  development  process  actually  followed  in  creating  this  Intranet  prototype  and 
explain  the  design  and  functionality  evolution  that  transpired  along  the  way. 
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VII.  RECOMMENDATIONS  FOR  INTRANET  OPERATIONS 


A.  INTRODUCTION 

The  planning  and  consideration  involved  in  developing  and  implementing  an 
Intranet  is  extensive.  With  no  prior  experience  in  developing  or  implementing  Intranets, 
our  research  in  this  area  focused  on  those  who  have  had  experience  and  have  shared  their 
lessons  learned.  This  chapter  contains  two  sections.  The  first  section  is  on  Intranet 
policy,  followed  by  a  lessons  learned  section,  which  documents  and  references  lessons 
learned  for  those  organizations  that  have  successfully  implemented  Intranets.  This 
section  includes  the  author's  recommendations,  which,  given  the  division's  current  umque 
situation,  provides  the  division  with  next  step  recommendations  for  implementing  their 
Intranet. 

B.  INTRANET  POLICY 

In  order  to  maintain  a  disciplined  Intranet  environment  it  is  absolutely  essential 
the  division  establish  an  Intranet  policy  that  will  guide  and  control  the  division's  Intranet 
efforts.  At  the  time  of  this  writing  the  Army  has  not  published  a  policy  concerning  the 
management  and  control  of  Army  Intranets.  Appendix  3  contains  a  30  October,  1996 
letter  released  by  LTG  Otto  J.  Guenther,  who  is  the  Army's  Director  of  Information 
System  for  Command,  Control,  Communications,  and  Computers  (DISC4),  entitled 
Guidance  for  the  Management  of  Army  Web  sites.  Although  it  does  not  specifically 
mention  Intranets,  much  of  the  guidance  set  forth  in  the  document  is  also  relevant  in  an 
Intranet  environment.  This  document  also  mentions  that  a  final  policy  is  being 
coordinated. 
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1.  Security 

According  to  Stephen  Cobb,  director  of  special  projects  at  the  National  Computer 
Security  Association  (NCSA),  "If  you  are  not  ready  to  write  and  enforce  Web  specific 
security  policies,  then  you  are  not  ready  to  roll  out  an  Intranet"[7. 1].  A  formal  policy 
shows  that  an  organization  has  thought  ahead  and  considered  the  security  issues 
including,  how  to  combat  threats  to  security  and  actions  to  take  if  security  defenses  are 
breached. 

Intranet  Security  can  be  broken  down  into  two  primary  areas,  content  security  and 
access  security.  Content  security  concerns  the  classification  level  of  the  information 
which  will  be  published  on  the  Intranet.  Access  security  is  allowing  only  authorized 
users  (those  with  a  valid  login)  to  be  able  to  access  the  content  on  your  Intranet.  Once  on 
the  network,  access  control  can  be  used  to  allow  only  those  given  permission  to  access 
certain  pages  on  the  Intranet. 

2.  Content 

What  information  will  be  required  to  be  posted  on  the  Intranet?  Will  there  be  a 
standard  look  (i.e.,  division  symbol  on  each  page,  etc.)  for  each  published  web  page? 
What  will  be  the  size  limitation  for  each  web  page  produced  (larger  files  require  longer 
download  times)?  What  will  be  the  content  security  classification  limitation  for  web 
documents  posted  on  the  Intranet?  Who  will  be  responsible  for  production  of  web  pages? 
Who  will  be  given  the  authorization  to  identify  what  will  and  will  not  be  posted  on  the 
Intranet?  Who  will  be  ultimately  responsible  for  the  content  on  the  Intranet?  These  are 
just  a  few  of  the  many  questions,  which  will  have  to  be  addressed  in  the  content  portion 
of  the  policy  document.  In  order  to  enforce  established  guidance  and  policy  in  this  area. 
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it  is  imperative  the  division  also  has  in  place  a  corresponding  mechanism  to  ensure  that 
members  of  the  division  adhere  to  the  written  policy.  Some  other  areas,  which  fall  under 
the  content  heading,  include  maintenance  and  web  page  posting.  Consideration  is  going 
to  have  to  be  given  to  how  often  web  pages  will  be  reviewed,  updated,  and  removed. 
What  about  the  posting  of  web  pages?  Will  this  responsibility  rest  totally  with  the 
division's  webmaster? 

3.  Applications 

In-line  with  the  RCAS  fielding,  the  division  has  established  Microsoft  Office  Pro 
as  the  standard  office  automation  suite.  The  tools  operate  in  a  somewhat  seamless 
Windows  95  environment  where  files  are  easily  shared  amongst  the  different  office  pro 
application  programs.  The  Office  Pro  97  version  gives  the  user  the  ability  to  save 
documents  in  HTML  format,  which  makes  the  publication  and  posting  of  web  material 
very  simple.  The  client/server  environment  was  explained  in  Chapter  II.  Recall  that 
when  the  client's  browser  downloads  a  specific  file  type  (i.e.,  .xls  file  extension, 
(Microsoft  Excel)),  in  order  to  view  the  file  on  the  client  machine  the  application  must  be 
installed  as  a  resident  program  on  the  client.  Policy  provisions  need  to  be  made  as  to 
which  file  types  will  be  made  available  for  download  on  the  Intranet.  The  use  of  Delrina 
FormFlo  is  widespread  throughout  the  Army  and  the  40*  Division.  A  few  forms  with  the 
.frz  extension  were  included  in  the  prototype  to  demonstrate  the  ease  and  usefulness  of 
the  application.  The  electronic  use  and  processing  of  Delrina  Forms  will  greatly  improve 
the  efficiency  in  which  administrative  forms  are  processed. 
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With  the  limited  amount  of  application  programs  available,  consideration  needs  to 
be  given  to  the  administrators  who  will  be  responsible  for  the  production  and  processing 
of  administrative  information. 

4.  Servers 

It  is  imperative  that  those  responsible  in  the  division  for  information  systems 
planning  understand  the  short  term  plans  and  long  term  vision  of  the  California  National 
Guard  and  the  RCAS  system.  In  addition,  they  must  understand  the  DOD  IT  twenty-one 
initiatives  which  includes  the  Army's  Technical  Architecture  and  the  information 
technology  standards  that  are  being  established.  Being  able  to  understand  the  vision  of 
the  state  and  National  Guard  bureau  and  following  the  standards  being  established  in  the 
RCAS  and  the  ATA  will  allow  the  division  to  better  posture  itself  for  receipt  of  the 
program-funded  RCAS  hardware  and  software  components.  The  state  anticipates  it  will 
begin  receiving  RCAS  funding  support  in  the  2QTR  of  FY98. 

Recall  from  the  client/server  model  presented  in  Chapter  II  that  the  web  materials 
(i.e.,  HTML  pages,  files  of  different  types,  etc.)  resides  on  the  server.  The  division 
Intranet  resides  on  one  machine  currently.  Will  maintaining  one  server  at  a  single 
location  be  practical  for  the  division  in  the  future  as  the  Intranet  grows?  How  many 
servers  are  practical,  affordable,  and  reasonable?  Does  it  make  sense  to  have  one  for 
every  brigade  level  element?  These  are  the  types  of  questions  that  the  Division 
Information  Management  Advisory  Council  (DIMAC)  will  eventually  have  to  address. 
The  division  has  standardized  the  division's  network  operating  system  as  Microsoft  NT 
4.0.  NT  4.0  comes  bundled  with  Internet  Information  Server,  which  is  Microsoft’s  web 
server  software. 
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NT  Server  is  one  of  the  compatible  operating  systems  that  have  been  identified  in 
the  Army's  Technical  Architecture  and  will  be  the  primary  server  operating  system  for 
the  RCAS  system. 

Eventually  the  division  will  want  to  decentralize  the  content  development  process. 
Prior  to  the  decentralization,  consideration  will  have  to  be  given  to  training  qualified 
personnel  (i.e.,  subordinate  unit  webmasters)  who  will  be  able  to  prepare  and  post  unit 
content  and  coordinate  with  the  division's  webmaster. 

5.  Client 

Because  of  the  no-cost  download  available,  the  Division  Information 
Management  Advisory  Council  (DIMAC)  has  decided  on  Microsoft's  Internet  Explorer 
(IE)  as  the  default  browser  for  users  on  the  Division's  Intranet.  The  server-based  web 
content  is  currently  being  developed  with  the  assumption  that  most  of  the  users  will  be 
using  the  freely  available  IE.  Although  other  browser  types  can  be  used,  web  page 
appearance  will  not  always  be  guaranteed  unless  using  IE.  Some  of  the  interactive 
content  (i.e.,  ActiveX,  plug-ins,  etc.)  requires  the  use  of  Internet  Explorer. 

Because  access  will  be  limited  to  the  Intranet  initially,  acceptable  usage  should 
not  be  an  issue.  When  the  capability  to  access  the  Internet  arrives  at  the  division  (see 
RCAS  architecture),  the  division  will  have  to  implement  policy  that  indicates  what  kind 
of  usage  is  acceptable  (i.e.,  authorized  surfing).  If  the  division  feels  that  enforcing  policy 
by  tracking  visited  web  sites  is  a  necessity,  there  are  network  management  tools  for  sale 
that  allow  network  administrators  the  ability  to  track  network  client  usage  of  the  Internet. 

Training  is  another  issue  which  will  have  to  be  addressed  by  the  DIMAC. 
Although  learning  and  using  a  browser  are  easy  things  to  do,  consideration  still  needs  to 
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be  given  to  those  personnel  in  the  division  who  have  never  been  exposed  to  browsers  and 
the  internet.  An  approach  would  be  to  coordinate  the  development  of  a  New  Equipment 
Training  Team  (NETT)  which  could  travel  to  the  different  units  within  the  division  to 
conduct  web  browser/intranet  training.  A  less  expensive  method  would  be  to  take  a 
"Train  the  trainer"  approach.  Training  packages  could  be  developed  and  posted  on  the 
Intranet.  This  would  be  followed  by  an  identification  and  recruitment  of  unit  level 
personnel  who  are  computer  proficient.  The  training  packages  would  be  thorough 
enough  to  provide  the  trainers  with  an  outline  of  what  material  should  be  covered,  along 
with  ideas  and  teaching  techniques  that  will  enforce  learning. 

C.  LESSONS  LEARNED  AND  RECOMMENDATIONS 

Although  certainly  not  all  encompassing,  this  section  provides  the  reader  with 
some  of  the  lessons  learned  by  other  organizations  in  the  area  of  Intranet  development 
and  operations.  The  intent  of  this  section  is  to  not  only  provide  the  customer  with  lessons 
learned,  but  also  to  discuss  the  lessons  learned  in  the  context  of  the  division's  current 
situation.  The  following  is  a  list  of  eight  recommended  steps  the  division  should  follow 
in  order  to  achieve  success  in  the  early  stages  of  bringing  up  the  Intranet.  These  steps  are 
not  listed  in  any  particular  order  and  are  a  compilation  of  the  ideas  extracted  from  various 
Intranet  readings.  [7.2, 7.3,  7.4,  7.5,  7.6] 

1.  Responsibility 

What  may  seem  obvious  in  a  military  enviromnent  is  not  necessarily  so.  In  order 
for  the  Intranet  development  to  move  forward  and  progress,  responsibility  and 
accoimtability  have  to  be  assigned.  Someone  in  the  organization  will  ultimately  have  to 
be  the  decision-maker  when  it  comes  to  decisions  concerning  the  Intranet.  This  person  is 
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the  G-6,  responsible  for  information  technology  management  in  the  division.  The  G-6's 
officer  representative  for  automation  affairs  in  the  division  is  the  Division  Automation 
Officer  (DAMO).  The  DAMO  should  be  a  person  who  not  only  has  a  good  imderstanding 
of  the  technology,  but,  most  importantly,  has  a  clear  imderstanding  of  the  division's  goals, 
and  is  politically  up  to  the  task  of  working  with  differing  personalities  and  conflicting 
ideas.  [7.2] 

The  division  G-6  should  consider  establishing  a  position  for  the  division's 
webmaster.  This  position  would  be  a  full  time  job  best  held  by  a  techmcally  astute  senior 
NCO.  This  NCO  would  be  responsible  for  the  day  to  day  operations  of  the  Intranet. 
Written  policy,  which  will  be  addressed  in  one  of  the  following  steps,  will  have  to 
address  the  full  scope  of  the  duties  and  responsibilities  associated  with  being  the 
division's  webmaster.  It  will  be  extremely  important  for  the  division's  webmaster  to 
understand  the  vision  and  intent  of  the  G-6.  The  division  webmaster  will  play  an  integral 
role  in  developing  the  division's  policy  for  Intranet  operations  as  a  member  of  the 
Division's  Information  Management  Advisory  Group  (DIMAC). 

2.  Strategic  Level  Planning 

With  the  Reserve  Component  Automation  System  (RCAS)  being  implemented 
throughout  the  division,  it  is  imperative  the  DIMAC  understand  the  state's  long-range 
strategic  level  automation  plans.  According  to  the  automation  representatives  at  the 
state's  National  Guard  headquarters  in  Sacramento,  federal  funding  for  the  RCAS 
program  is  due  in  the  2"*^  quarter  of  FY98.  All  initiatives  being  taken  now  by  the 
division,  including  the  further  development  and  implementation  of  the  Intranet,  should  be 
in-line  with  the  state-level  vision.  This  includes  those  efforts,  now  ongoing,  to  posture 
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the  division  to  receive  and  integrate  the  RCAS  system  into  the  state's  information 
infrastructure.  All  the  tasks  associated  with  the  RCAS  posturing,  Intranet 
implementation/operations,  and  RCAS  implementation  should  be  identified.  The 
necessary  resources  needed  to  accomplish  these  tasks  also  need  to  be  identified.  A  long- 
range  calendar  should  be  incorporated  in  the  Strategic  Plan,  which  depicts  the  events 
associated  with  the  state  and  division-level  vision  of  what  is  being  plaimed. 

Eventually,  the  division  headquarters  (i.e.,  G-6,  DAMO,  and  division  webmaster) 
is  going  to  want  to  decentralize  Intranet  control.  This  means  that  tasks  such  as 
production  and  posting  of  web  content  and  the  proliferation  and  control  of  subordinate 
unit  web  servers  will  eventually  be  given  to  Brigade  and  below  level  elements.  The 
impact  of  the  natural  decentralization  process  needs  to  be  considered  now  so  planning  for 
the  decentralization  can  take  place.  Some  of  the  impact  areas  which  need  to  be 
considered  in  a  short-term  strategic  plan  include;  identification  of  pre-Intranet  and  post- 
Intranet  processes  and  training  for  subordinate  unit  webmasters/system  administrators. 

3.  Intranet  Advisory  Team  [8.3] 

The  DIMAC  is  the  logical  choice  to  serve  as  the  nucleus  for  the  Intranet  advisory 
team.  A  user  representative  from  every  part  of  the  division,  including  each  echelon  from 
company  level  up  through  and  including  a  representative  from  the  state  headquarters  in 
Sacramento,  needs  to  be  included  as  a  member  of  this  team.  It  is  critical  that  the  Intranet 
is  serves  the  needs  of  the  user.  In  order  to  insure  this,  the  team  needs  to  consist  of  a 
representative  user  base  and  those  with  decision  authority  to  enact  proposals  presented  by 
the  team.  Initially,  the  team  will  have  the  lone  division  webmaster.  As  the  Intranet 
grows,  the  division  will  need  to  decentralize  control.  Eventually,  each  Brigade  size 
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element  and  ultimately  each  battalion  size  element  will  have  their  own  webmaster,  and 
they  should  be  added  to  the  team.  Before  the  decentralization  can  take  place,  a 
disciplined  strategic  approach  addressing  the  Intranet's  development  and  implementation 
will  have  to  be  developed  and  disseminated  by  the  DIMAC. 

4.  Intranet  Policy 

Section  B  of  this  chapter  discusses  the  importance  of  written  policy  covering 
Intranet  operations.  As  mentioned  previously,  the  Army  currently  has  a  three-page 
interim  policy  letter  signed  by  the  DISC4  that  discusses  Internet  web  policy.  A  more 
formal  policy  is  forthcoming.  There  are  a  number  of  corporations  who  have  put  together 
policy  regarding  Intranet  operations.  Unfortunately,  they  are  not  as  restrictive  and 
disciplined  as  we  believe  a  military  Intranet  policy  should  be.  The  areas  discussed  in 
section  B  should  be  researched  and  discussed  thoroughly,  with  decisions  made  in  these 
areas  published.  The  military  is  known  for  its  numerous  policy  letters,  which  cover  a 
wide  range  of  operational  activities  and  processes.  The  development  and  implementation 
of  an  Intranet  is  no  different.  The  fact  that  written  policy  must  be  developed  for  the 
division's  new  Intranet  can  not  be  overstated. 

5.  Funding 

Although  web  technology  is  relatively  inexpensive,  the  costs  associated  with  its 
operation  (i.e.,  servers,  authoring  tools,  client  workstations,  connectivity,  application 
software,  operating  system  software,  etc.)  have  got  to  be  identified.  What  resources  is  the 
division  responsible  for?  What  funding  will  the  state  provide  for  this  initiative?  What 
kind  of  resources  will  be  provided  by  the  federally  funded  RCAS  implementation?  These 
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and  questions  like  them  need  to  be  answered  in  order  to  adequately  plan  for  and  prepare 
for  Intranet  resourcing. 

6.  "Open"  Technical  Solutions 

Those  responsible  for  the  hardware  and  software  solutions  associated  with 
improving  the  Intranet's  current  capabilities  should  consult  the  automation  professionals 
at  the  state  headquarters  to  insure  any  proposed  solutions  are  in-line  and  compatible  with 
what  future  plans  call  for.  According  to  the  state  headquarters,  the  RCAS  Program 
Management  Office  will  begin  fielding  the  system  in  California. 

7.  Patience 

The  division  needs  to  look  at  the  Intranet  implementation  and  operations  from  a 
"crawl,  walk,  run"  perspective.  The  obvious  analogy  here  is  the  different  stages  of  a 
child's  mobility  development  (i.e.,  first  a  child  learns  how  to  crawl,  then  to  walk,  then  to 
run). 

a.  Crawl 

Upon  our  delivery  on  2  May,  1997,  the  division  decided  to 
immediately  put  the  prototype  on-line.  Having  just  received  the  operational  prototype,  the 
division  is  in  the  "crawl"  stage  and  will  have  to  spend  some  time  finishing  the  initial 
development.  The  prototype  contains  both  static  and  dynamic  (i.e.,  data  entry  pages 
working  with  a  back  end  database)  pages.  The  static  pages  that  were  created  contain 
some  worthwhile  information,  which,  of  course,  will  have  to  be  periodically  updated. 

The  dynamic  pages,  specifically  the  soldier  data  entry  forms  using  the  Open  Data  Base 
Cormectivity  (ODBC)  standard  to  store,  retrieve,  and  query  records  in  a  web 
environment,  were  developed  to  show  what  functionality  is  available.  The  team 
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recommends  the  division  continue  to  maintain  the  static  information  but  disable  the 
ODBC  portions  of  the  web  site  imtil  the  DIMAC  can  conduct  a  study  to  identify  what 
data  entry,  retrieval,  and  query  systems  will  be  developed  or  incorporated  into  the 
Intranet.  Before  the  division  starts  using  the  Intranet  for  storing  and  retrieving  vital  data, 
the  security  aspects  of  the  system  will  have  to  be  addressed  in  detail.  What  the  division 
does  not  want  is  to  put  itself  in  a  position  with  the  Intranet  where  sensitive  data  (i.e., 
personnel  information,  etc.)  could  be  accessed  without  authorization,  compromised,  or 
corrupted.  Each  case  where  there  is  a  desire  to  use  the  ODBC  functionality  and 
incorporate  data  storage  and  retrieval  'will  have  to  be  looked  at  on  an  individual  basis. 
Disciplined  policy  and  procedures  "will  have  to  be  enacted  which  discuss  access  security, 
storage,  back-ups,  data  recovery,  etc.  What  current  database  information  in  the  dmsion 
can  be  ported  over  to  the  Intranet  to  make  this  data  readily  available  throughout  the 
division?  Is  this  kind  of  thinking  in  line  with  what  the  state  and  the  RCAS  system  ■will 
provide  the  division?  Is  it  worth  the  time  and  resources  now  to  look  at  the  legacy  data 
storage  and  retrieval  systems  and  how  feasible  would  it  be  to  port  that  data  over  to  the 
Intranet?  Is  the  new  RCAS  system  going  to  contain  web  enabled  applications,  which  will 
provide  this  functionality?  These  and  many  other  similar  questions  will  have  to  be 
studied  and  addressed  by  the  DIMAC  before  databases  are  incorporated  into  the  Intranet. 
During  the  "crawl"  stage,  the  di-vision  should  be  promoting  and  selling  the  usefulness  of 
the  Intranet.  In  order  to  make  it  useful,  the  information  must  be  timely  and  informative. 
Current  di-vision  news,  unit  news,  training  schedules,  division  calendars,  downloadable 
forms,  briefings,  spreadsheets,  etc.  are  just  some  of  the  static  information  the  division  can 
be  providing  its  users.  Marketing  the  Intranet  at  this  stage  is  very  important  to  eventual 


99 


success.  The  word  has  to  be  put  out  to  all  soldiers  in  the  division  that  this  service  is 
available.  Instructions  should  accompany  the  division-wide  announcement  on  how 
individuals  can  obtain  accoimts.  All  members  of  the  division  should  consider  the  Intranet 
"their"  Intranet  and  their  primary  source  of  division-wide  information. 

b.  Walk 

With  the  Intranet  on-line  and  the  division  wanting  the  utility  of  the 
Intranet  to  increase,  the  G-6,  the  DAMO,  and  the  DIMAC  certainly  have  their  work  cut 
out.  One  of  the  first  concerns  that  will  have  to  be  addressed  is  the  traffic  load  dialing  into 
the  division's  modem  bank  to  gain  access  to  the  Intranet.  The  division  currently  has  only 
ten  1-800  lines  and  approximately  250  authorized  users  with  assigned  logins  and  this 
number  is  growing.  It  is  just  a  matter  of  time  before  the  10  lines  will  reach  a  point  of 
saturation  and  all  a  user  will  hear  when  he  dials  in  to  the  division's  modem  bank  is  a  busy 
signal,  which  can  lead  to  discouragement  rather  quickly  and  cause  people  to  discredit  the 
Intranet.  A  modem  ratio  is  the  number  of  registered  users  to  the  total  nximber  of  modems 
in  the  modem  bank.  Internet  Service  Providers  (ISP)  know  it  is  time  to  add  more  phone 
lines/modems  when  they  receive  complaints  about  busy  signals.  To  many  U.S.  providers, 
the  modem  ratio  is  proprietary  information  they  do  not  wish  to  share.  Those  touting  a  no 
busy  signal  guarantee  usually  listed  figures  ranging  fi'om  10:1  to  15:1.  The  first  case 
represents  10  registered  users  to  every  1  modem  in  the  modem  bank.  It  can  be  seen  that 
with  250  registered  users  and  only  10  available  phone  line/modems,  the  divisions  modem 
ratio  is  already  at  25:1 .  The  DIMAC  should  eonsider  when  and  how  they  would  expand 
the  current  1 0  line/modem  capability.  This  is  an  area  which  the  division  will  have  to  keep 
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an  eye  on  very  closely  in  order  to  provide  the  best  possible  service  to  Intranet  users  and 
promote  Intranet  use. 

Education  and  training  are  other  areas  the  DIMAC  will  have  to 
address.  Deciding  who  will  train,  how,  and  what  they  will  train  are  probably  the  biggest 
questions  that  need  to  be  wrestled  with  in  the  short  term. 

Also,  imderstanding  the  state's  long  term  plan  for  information 
operations  (i.e.,  RCAS,  use  of  legacy  systems,  data  usage,  etc.)  is  critical  for  the  DIMAC. 
Before  any  Intranet  expansion  occurs  (i.e.,  the  purchase  of  additional  servers, 
applications,  modems,  phone  lines,  etc.),  the  division  should  draft  proposals  to  the  state 
national  guard  bureau  to  ensure  that  the  proposed  Intranet  expansion  is  in-line  with  the 
state's  long  term  information  operations  vision. 

Dynamic  web  capabilities  offer  a  powerful  tool  to  the  division. 

The  ability  to  enter,  retrieve,  and  query  information  from  a  database  gives  the  division  a 
decision  support  capability.  Information  can  be  put  literally  at  the  fingertips  of  decision¬ 
makers  authorized  to  access  and  query  databases  for  the  specific  data  they  are  looking 
for.  Databases  of  different  types  are  currently  maintained  such  areas  as  personnel, 
security,  operations,  and  logistics.  Recommend  that  the  DIMAC  prioritize  the  areas 
which  would  benefit  the  most  by  the  development  and  implementation  of  a  web  based 
dynamic  environment  where  records  can  be  queried,  added  to,  updated,  and  deleted  from 
dedicated  databases.  As  mentioned  previously,  the  DIMAC  will  have  to  scrutinize  each 
dynamic  area  developed  in  order  to  ensure  the  safeguard  of  sensitive  data.  Once 
developed  and  approved  for  implementation  into  the  Intranet,  only  one  dynamic  area  at  a 
time  should  be  implemented.  It  is  recommended  that  a  simple  area  be  developed  initially. 
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Redundancy  and  fault  tolerance  need  to  be  built  into  the  implementation  plan  as  a 
safeguard  measure. 

c.  Run 

The  division  is  going  to  want  to  decentralize  the  Intranet.  Currently,  the 
division's  Intranet  is  operating  from  one  server  machine  with  a  couple  of  soldiers  playing 
the  part  of  interim  webmasters.  Eventually,  the  Brigades  and  possibly  the  battalions  will 
want  to  maintain  their  own  web  servers.  Given  authorization,  brigade  and  battalion  level 
webmasters  can  update  information  on  the  lone  division  server.  This  process,  however, 
can  be  slow  and  cumbersome  and  opens  up  the  division  server  to  uimecessary  and 
potentially  dangerous  access.  With  the  growth  of  the  Intranet,  entity  sites  (i.e.,  brigade 
and  battalions)  are  easier  to  maintain  with  their  own  resident  server.  Given  their  own 
server,  webmasters  at  the  brigade  and  battalion  levels  will  better  be  able  to  manage  their 
own  sites. 

In  order  to  decentralize  the  Intranet,  the  division  is  going  to  have  to 
provide  its  subordinate  brigades  with  the  necessary  resources  (i.e.,  server,  web 
development  tools,  training  for  webmasters,  etc.). 

The  addition  of  dynamic  areas  will  continue  in  the  run  phase. 

8.  Intranet  Promotion  [7.4] 

In  order  for  the  Intranet  to  be  successful,  it  has  to  be  valued  as  useful  by  its  users. 
If  content  is  not  kept  up  to  date,  users  will  seek  other,  more  reliable  forms  of  information. 
If  the  Intranet  is  providing  useful  information  to  the  division's  users,  it  should  be 
promoted  from  the  top.  The  Commanding  General,  the  Assistant  Division  Commanders, 
the  Division  Sergeant  Major,  the  Chief  of  Staff  and  the  rest  of  the  leadership  in  the 
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division  should  play  an  active  role  in  promoting  the  use  and  gradual  development  and 
improvement  of  the  Intranet. 

D.  CONCLUSION 

The  division  Intranet  is  new  and  the  information  operations  associated  with  the 
Intranet  are  new  as  well.  Information  technology  has  changed  the  way  we  work  and 
unless  the  division  embraces  the  Intranet  and  addresses  the  difficulties  associated  with 
“change”  in  the  work  place,  the  Intranet  runs  the  risk  of  being  discredited  or,  even  worse, 
dying  an  early  death.  This  chapter  discussed  Intranet  policy  and  lessons  learned  and 
hopefully  has  given  the  division  some  ideas  on  how  to  successfully  implement  their 
Intranet. 
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APPENDIX  A.  TRIP  REPORT  1 


Trip  Report  -Visit  to  California  National  Guard  40*''  Division  Headquarters  - 
Cypress  California  - 19  Dec.  1996 

We  met  with  LTC  Rod  Barham,  the  240***  Signal  Battalion  Commander  for  the 
40*''  Infantry  Division  (Mechanized)  around  10:00  AM,  19  Dec.,  at  the  40**’  Division 
Headquarters  located  in  Cypress  California.  LTC  Barham  is  the  Division  Automation 
Officer  (DAMO)  responsible  for  the  operation  and  maintenance  of  all  automation 
equipment  within  the  division. 

MAJ  Heckroth  and  I  put  together  a  briefing  to  guide  us  through  our  initial 
meeting  with  LTC  Barham.  Our  intent  was  to  follow  the  content  of  our  briefing,  which 
includes  our  project’s  scope,  goals,  and  objectives.  The  briefing  concludes  with  a  student 
checklist  that  we  put  together  to  insure  we  had  the  information  we  needed  for  the  next 
phase  of  our  project. 

LTC  Barham  also  prepared  a  briefing  that  gave  us  an  initiation  into  the 
automation  situation  within  the  division.  In  order  to  get  better  acquainted,  we  shared  our 
military  experience  backgrounds  with  LTC  Barham  and  he  gave  us  a  brief  background  on 
his  military  service  experience. 

LTC  Barham  spent  eight  years  in  the  Pentagon  at  the  National  Guard  Bureau.  His 
position  at  the  Bureau  was  as  an  Information  Systems  Manager/Developer.  He  later  spent 
some  time  as  an  automation  professional  at  the  Program  Executive  Office  (PEO)  for 
Standardized  Army  Management  Information  Systems  (STAMIS).  LTC  Barham  said  he 
was  very  familiar  with  the  now  defunct  Reserve  Component  Automation  System 
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(RCAS).  He  said  the  1.5  billion  dollar  program,  which  ran  on  a  UNIX  platform  in  a 
client  server  environment,  was  a  multilevel  security  system  that  was  proprietary  in  nature, 
very  cumbersome  and  not  an  intuitive  system  for  new  users.  The  system,  which  was  to 
improve  readiness  by  providing  digital  connectivity  to  geographically  dispersed  National 
Guard  units,  was  scrapped  only  twelve  months  ago  after  an  outlay  of  nearly  2  billion 
dollars. 

The  California  National  Guard  was  the  first  unit  to  field  the  “old”  RCAS  system. 
LTC  Barham  informed  us  that  they  (California)  would  be  the  last  to  field  the  “new” 
RCAS  system  because  of  their  high  priority  in  the  initial  fielding.  The  California 
National  Guard  is  not  due  to  receive  their  “new”  RCAS  system  until  the  year  2002. 

LTC  Barham,  as  the  Divison’s  senior  signal  officer  and  automation  officer,  was 
tasked  to  come  up  with  an  interim  system  that  would  provide  the  division  Avith  a  digital 
messaging  capability  with  coimectivity  to  all  the  division’s  subordinate  elements.  In 
addition  to  a  digital  messaging  capability,  the  division  specified  a  general  requirement  of 
having  the  capability  to  share  data.  LTC  Barham’s  briefing  was  the  same  briefing  he  had 
given  to  the  division’s  Chief  of  Staff  and  specified  his  short,  medium,  and  long  term 
objectives  for  the  division  in  the  area  of  automation. 

He  mentioned  that  his  number  one  short-term  objective  was  to  give  the  division 
its  own  electronic  mail  (e-mail)  capability.  At  present,  soldiers  within  the  division  that 
want  to  conduct  National  Guard  business  (i.e.,  coordination,  information  dissemination, 
control,  etc.)  using  electronic  mail,  do  it  at  their  own  expense  (using  a  local  or  national 
Internet  Service  Provider  (ISP)  mail  server). 
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LTC  Barham  is  in  the  process  of  setting  up  what  he  is  calling  the  Division 
Bulletin  Board  Service  (BBS).  Following  our  morning  meeting  with  LTC  Barham,  we 
met  with  SSG  Gregory  Holmes,  an  NCO  from  the  Division  Material  Management 
Center’s  (DMMC)  Logistics  Automation  Service  Support  Office  (LASSO),  who  has 
volunteered  his  services  in  setting  up  the  Division’s  initial  BBS/email  capability. 

Our  meeting  with  LTC  Barham  lasted  nearly  three  hours.  Our  discussion  covered 
a  wide  area  of  topics.  The  following  areas  of  discussion  are  worthy  of  further  mention: 

•  User  Survey  -  We  showed  him  an  example  of  a  survey  that  could  be 
distributed  throughout  the  division  to  collect  information  with  regard  to  user's 
wants  and  needs.  He  was  extremely  interested  in  possibly  modifying  the 
questionnaire  and  distributing  it  throughout  the  division  in  order  to  “check  the 
pulse”  of  the  division.  MAJ  Heckroth  and  MAJ  Olson  thought  this  would  be 
a  good  idea.  LTC  Barham  has  “got  the  ball”  on  the  user  survey. 

•  “As-Is”  System  -  LTC  Barham  was  interested  in  coming  up  with  an  “as-is” 
IDEF  model  similar  to  the  Data  Flow  Diagrams  (DFDs)  we  put  together  for 
our  IS4200  projects.  The  “as-is”  system  would  depict  garrison  information 
flow  within  the  division. 

•  Operational  Concept  -  The  new  “BBS”  system  the  division  is  bringing  on¬ 
line  will  need  to  be  maintained  (i.e.,  system  administered  to  add,  update,  and 
delete  users).  When  the  proposed  Webserver  is  brought  on-line,  policy  and 
guidance  (i.e.,  an  SOP)  is  going  to  have  to  be  provided  to  website  content 
providers  in  order  to  insure  that  only  standard,  disciplined,  and  useful  content 
reflecting  the  pride  of  the  Division  is  allowed  to  be  published.  All  meeting 
participants  felt  this  was  a  critical  component  in  order  to  maintain  discipline 
and  control  of  the  internal  website. 

•  Current  Vision  -  LTC  Barham’s  short-term  vision  is  bringing  up  his  “BBS” 
as  soon  as  possible  and  giving  each  HQs  element,  from  division  through 
company  level,  an  email  account.  In  addition,  each  primary  division  staff 
element  would  be  given  an  email  account.  According  to  SSG  Holmes,  the 
initial  BBS  will  consist  of  a  standard  telephone  line,  which  terminates  into  a 
ring  of  eight  modems.  The  “BBS”  hardware  platform  is  a  166MHZ  Pentium 
Gateway  Computer.  The  “BBS”  server  software  is  called  TSX-Online.  TSX 
is  a  stand-alone  operating  system,  which  also  has  Internet  Service  Provider 
(ISP)  software  functionality,  which  provides  the  Divsion’s  dial-in  users  with 
a  gateway  to  its  mail  server  (a  TSX  utility)  and  web  server  (Internet 
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Information  Server  IIS,  a  Microsoft  product).  This  product  is  to  be  used  as  a 
gateway,  with  a  parallel  machine(s)  running  applications  in  an  NT 
environment. 

•  Key  Question  -  One  of  the  key  questions  that  was  discussed  with  Barham 
and  Holmes  is  connectivity.  If  each  HQs  element,  from  division  dovm  to 
company  level,  plus  each  primary  staffer  at  Division  is  given  an  email  accovmt 
and  each  of  these  mentioned  entities  checks  their  mail  three  times  a  day,  is 
eight  modems  enough  to  provide  quality  service  (no  busy  signals  when  ISP  is 
called  to  download  mail)?  There  is  nothing  more  frustrating  than  trying  to 
gain  access  to  a  dial-in  host  computer  and  receiving  a  busy  signal.  Physical 
connectivity  was  also  an  issue  of  discussion.  According  to  Barham  and 
Holmes,  the  location  of  the  initial  BBS  will  be  established  at  the  Division 
Support  Command’s  (DISCOM)  Logistical  Automation  System  Support 
Office  (LASSO)  located  at  3700  East  Spring  Street,  Long  Beach,  CA.  Those 
Division  elements  that  are  co-located  with  the  Division  LASSO  will  have 
direct  connectivity  to  the  mailserver  and  Webserver  via  local  area  network. 
Others  will  have  to  dial-in  to  the  server  or  have  a  dedicated  line  to  the 
LASSOs  location.  The  concerns  over  traffic  volume  are  magnified  wdth  the 
addition  of  the  Webserver  to  the  network,  (users  stay  connected  while 
“surfing”  vice  mail  upload/download  then  dropping  connection).  Discussion 
leaned  toward  a  traffic  volume  study  that  would  give  the  division  an 
indication  of  the  number  of  dial-in  modems  and  direct  connect  lines  they 
would  need  to  provide  quality  service  to  its  customers. 

•  Administrative  Forms  -  A  separate  problem,  but  one  LTC  Barham  would 
like  to  address,  is  the  idea  of  getting  frequently  used  administrative  forms  on¬ 
line  in  a  distributed  environment  so  they  can  be  accessed  by  division 
personnel.  He  mentioned  programs  (ProForms  and  Forms  Engines)  that  are 
currently  used  in  the  Army  for  electronic  preparation  and  transmission  of 
admin  forms. 

•  Information  Modernization  Plan  -  LTC  Barham  is  currently  writing  the 
40*  Division’s  Information  Modernization  Plan.  He  gave  us  a  copy  of  the 
National  Guard’s  1995  Modernization  Plan  he  published  while  an  Information 
Officer  at  the  Pentagon. 

•  Prototype  Discussion  -  In  an  attempt  to  scope  our  project  prototype,  we 
asked  LTC  Barham  for  a  vision  of  what  he  considered  potential  areas  for 
initial  development  of  both  static  and  dynamic  web  pages.  He  said  that' there 
are  three  primary  critical  information  areas  that  we  could  incorporate  in  a  web 
prototype.  They  are  readiness,  USR  reporting,  and  training  schedules.  In 
reference  to  training  schedules,  LTC  Barham  mentioned  that  there  is  an  active 
Army  training  scheduler  currently  in  use.  He  told  us  that  he  would  try  to  get 
some  additional  information  on  the  program.  We  told  LTC  Barham  and  SSG 
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Holmes  that  we  would  pursue  the  design  and  development  of  a  dynamic 
prototype  in  this  area.  We  also  agreed  to  come  up  with  a  group  of  static  pages 
that  would  provide  a  hierarchical  shell,  beginning  with  a  division  homepage, 
with  links  to  each  division  staff  element  and  each  of  the  Brigades  and  separate 
Battalions  (i.e..  Air  Defense,  Signal,  Engineers,  etc.). 

•  Student  Information  Requirements  -  Information  LTC  Barham  agreed  to 
provide  students: 

•  Division  Organization  Chart  with  locations  of  units  down  to  the  company 
level 

•  Executive  Summary  of  “old”  and  “new”  RCAS  systems 

•  Information  on  how  the  Guard  does  business  in  the  three  critical  information 
areas:  readiness,  USR  reporting,  and  training  schedules.  In  order  to  develop 
databases  and  dynamic  web  pages  that  will  allow  a  user  to  input,  update,  and 
query  information,  the  developers  will  need  all  the  forms  (which  contain 
database  fields  information)  that  are  currently  used  in  reporting  and 
processing  information  in  these  areas. 

•  Results  from  previous  survey  and  decision  whether  to  go  ahead  with  new 
imit’s  requirements  survey 

•  As  much  “As-Is”  system  information  that  you  can  possibly  get  your  hands  on. 
This  is  critical  in  order  to  put  together  a  quality  “As-Is”  IDEE  model. 

•  Public  Affairs  Opportunities  -  LTC  Barham  mentioned  that  he  wanted  to 
capitalize  on  the  public  affairs  opportunities  that  will  present  themselves  in 
this  project.  The  students  agreed  they  would  participate  to  whatever  degree 
the  LTC  felt  was  appropriate. 

•  Ground  Rules  -  LTC  Barham  said  the  only  ground  rule  he  has  is  that  we  let 
him  review  any  published  documents  for  suitable  National  Guard  content. 
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APPENDIX  B.  TRIP  REPORT  2 


Visit  to  California  National  Guard  40*''  Division  Headquarters-  Cypress,  California- 
28  Feb  1997 

This  is  the  second  in  a  series  of  trip  reports.  We  linked  up  with  LTC  Scott,  the 
Division  G-6/Garrision  Commander,  at  around  08:15.  The  NPS  thesis  team  of  MAJ  Tom 
Heckroth,  USMC  and  MAJ  Tom  Olson,  USA  had  made  prior  coordination  with  LTC 
Scott  to  meet  with  representatives  from  each  of  the  G-shops  to  give  them  an  Intranet 
demonstration  and  to  gather  requirements.  We  had  the  pleasure  of  meeting  the  Division's 
Chief  of  Staff,  Colonel  Combs,  and  the  Commanding  General  for  the  40*'’  Division, 
Brigadier  General  Edmvuid  C.  Zysk  before  the  day's  meetings  began. 

During  our  discussions  vrith  Colonel  Combs,  we  discussed  our  intent  to  recruit 
two  more  thesis  students  from  NPS  that  would  follow-on  and  continue  to  build  the 
Division's  Intranet.  An  excellent  opportunity  exists  to  build  a  habitual  relationship 
between  the  systems  management  department  at  NPS  and  the  40th  Division,  which 
comprises  80%  of  the  California  National  Guard.  We  felt  it  was  a  good  time  to  bring  up 
the  funding  issue.  MAJ  Heckroth  and  I  personally  funded  the  two-day  trip  to  Cypress  in 
December  1996.  We  did  receive  funding  from  NPS  for  this  trip.  Future  trips  will  have  to 
be  personally  funded  by  the  students  unless  a  sponsor  steps  forward  to  help  defer  costs. 
There  are  other  areas  where  financial  support  is  critical  in  order  for  NPS  to  continue  to 
support  the  Intranet  system  development.  One  of  these  areas  is  equipment  support.  The 
development  team  is  currently  using  one  machine  that  is  on  loan  and  could  be  taken  from 
the  team  on  a  moment's  notice.  The  team  is  asking  for  the  funding  to  purchase  two 
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200MHZ  Pentium  pro  systems  that  will  serve  as  their  development  platforms.  In  addition, 
the  team  will  need  two  copies  of  Microsoft  Windows  NT  4.0.  The  new  machines  will 
greatly  increase  the  productivity  of  the  development  team.  The  job  of  recruiting  and 
securing  follow-on  students  will  also  be  made  easier  if  prospective  thesis  students  know 
they  have  guaranteed  production  resources  to  help  them  complete  their  thesis.  We  feel 
that  without  adequate  resource  support  in  the  future,  our  production  capabilities  and 
development  productivity  will  be  severely  degraded.  We  look  forward  to  further 
discussions  with  the  division  concerning  the  necessary  resource  funding. 

We  linked  up  with  our  sponsor,  LTC  Rod  Barham,  Commander  of  the  240th 
Signal  Battalion,  at  around  08:45.  We  retired  to  the  Division's  conference  room  to  brief 
our  sponsor  on  what  we  had  accomplished  since  our  last  meeting  on  19  December  1996. 

Our  intent  for  this  trip  was  to  get  back  together  with  our  sponsor  (customer)  to 
make  sure  the  work  we  had  done  was  in  line  with  his  expectations  and  vision  and  also  to 
collect  further  guidance  and  requirements. 

We  discussed  with  LTC  Barham  the  intent  of  our  visit  and  set  up  our  notebook 
computer  to  give  LTC  Barham  a  demonstration  of  the  work  we  have  done  since 
December.  The  team  told  LTC  Barham  how  we  felt  we  had  lost  about  thirty  days  learning 
the  development  tools  (Microsoft  Internet  Information  Server  (IIS  3.0),  Microsoft 
Frontpage,  and  Microsoft  NT  Server)  the  division  has  established  as  their  standard  tools. 
Back  in  December,  the  team  opted  to  learn  and  use  the  tools  the  division  was  using.  We 
decided  that  if  the  division  wants  to  keep  and  implement  the  student's  prototype  at  the 
end  of  the  project,  they  could  port  the  work  over  to  a  system  using  the  same  tools,  thus 
eliminating  any  compatibility  problems. 
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As  mentioned  earlier,  advance  coordination  was  made  by  the  team  to  meet  with 
each  of  the  division  headquarters  G  sections  to  demonstrate  our  work  to  date  and  discuss 
with  each  section  their  potential  web  content.  The  intent  was  to  explain  the  purpose  of  the 
Division's  Intranet,  give  the  demo,  and  discuss  requirements,  wants,  and  needs. 

LTC  Barham  and  MAJ  Willand,  the  headquarters  Commandant,  received  the  first 
of  five  demos  we  gave  throughout  the  day.  MAJ  Willand,  who  is  also  an  automator  and 
does  a  lot  of  briefing  preparation  and  graphic  design  work  for  the  division  headquarters 
(copy  of  division's  80th  Anniversary  program  enclosed  for  thesis  advisor  Suresh  Sridar) 
lent  us  an  external  monitor  for  the  day's  demos.  MAJ  Willand  told  the  team  he  would 
provide  us  with  digital  copies  of  pictures  of  the  commanders  and  primary  staff  to 
incorporate  into  the  division's  Intranet.  Unfortunately,  the  team  failed  to  get  back  with 
MAJ  Willand  to  secure  the  digital  copies  prior  to  our  departure  from  division 
headquarters.  The  team  will  coordinate  with  MAJ  Willand  for  electronic  transfer  of  the 
information. 

In  our  discussion  with  the  G3,  his  initial  concerns  were  with  the  security  aspects 
of  the  system.  Informing  him  that  there  would  be  no  classified  message  traffic  permitted 
on  the  system,  he  was  still  concerned  about  the  compromise  of  privacy  act  information 
(i.e.,  social  security  numbers).  We  assured  him  that  the  system  is  an  internal  (Intranet) 
network  that  will  be  accessible  only  to  authorized  users.  Only  a  certain  munber  of  the 
authorized  users  will  be  given  access  permission  to  personnel  records  for  the  purpose  of 
maintaining  those  records. 

The  G3  asked  where,  in  relation  to  the  SIDPERS  database  (U.S.  Army's  personnel 
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database),  will  the  new  Intranet  system  fit  in?  His  concern  is  that  with  the  introduction  of 
this  new  system,  which  is  tracking  similar  data,  twice  as  much  time  will  be  spent  entering 
the  same  data.  LTC  Barham  made  the  point  that  because  SIDPERS  is  a  higher 
headquarters  information  system,  it  is  a  political  football  that  needs  to  be  treated  with  kid 
gloves.  All  the  discussion  participants  expressed  their  frustration  with  the  current 
SIDPERS  system  and  its  inability  to  provide  the  division  with  timely,  updated,  and 
accurate  data. 

Discussion  turned  to  training  and  training  schedules.  We  showed  the  G3  the  demo 
copy  of  the  training  schedule  that  we  put  together.  The  point  was  made  that  not  only  the 
G3  but  the  division  as  a  whole  (G1-G6)  really  needs  an  all  encompassing  calendar  that 
would  be  useful  in  tracking  and  resolving  activities  within  the  division.  We  noticed  that 
Calendar  Creator  Plus,  a  software  calendar  tool,  was  in  widespread  use  throughout  the 
division  headquarters.  The  development  team  will  check  with  the  vendor  to  see  if  the 
newest  version  of  the  software  is  hypertext  mark-up  language  (HTML)  compliant,  which 
will  enable  the  calendars  to  be  posted  to  the  Intranet.  Someone  mentioned  how  useful  it 
would  be  to  "drill  down"  to  a  battalion's  page  and  see  what  kind  of  upcoming  events  they 
had  on  their  battalion  calendar. 

SGM  DeAmicis  gave  the  team  a  CD  copy  of  the  Standard  Army  Training  System 
V4.0.  He  mentioned  that  V4.1  was  just  released  or  is  due  to  be  released  shortly.  The  team 
will  inquire  with  the  program's  developer  on  version  V4. 1  and  will  look  into  how  this 
program  can  be  incorporated  into  the  Intranet. 

The  G-3  inquired  about  a  system  "chat"  capability  where  users  could  conduct  real 
time  interactive  text  transmissions  over  the  network.  He  mentioned  that  he  currently 
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conducts  chat  sessions  with  members  of  his  G-3  staff  to  conduct  remote  planning 
sessions.  The  idea  evolved  out  of  the  need  to  conduct  "dark  night"  planning  sessions, 
where  commanders  and  staffs  traditionally  would  have  to  travel  to  a  meeting  place  to 
conduct  planning  for  upcoming  guard  training  weekends.  The  remote  chat  sessions  allow 
the  commanders  and  staffs  the  convenience  of  remaining  geographically  dispersed  and 
conducting  their  planning  sessions  on-line.  Microsoft  NT  Server  v4.0  with  service  pack 
2,  which  will  reside  on  the  division's  Intranet  server,  comes  bimdled  with  a  program 
called  NetMeeting.  The  team  has  not  had  the  opportunity  to  look  into  the  program's 
capabilities/limitations  but  understands  the  program  has  both  a  "chat"  and  "whiteboard" 
capability. 

Potential  content  areas  for  the  G-3  include  posting  areas  for  exercise  operations 
orders  (OPORDS)  and  fragmentary  orders  (FRAGOS). 

The  capability  to  scrub  the  Unit  Status  Report  (USR)  at  each  echelon  level,  from 
company  through  division,  was  discussed.  The  team  expressed  the  need  to  better 
imderstand  the  USR  process  so  that  we  could  better  understand  how  the  USR  process 
could  be  improved  through  the  use  of  the  Intranet. 

MAJ  Russ  Gamer,  a  member  of  the  G-3's  staff  and  the  division's  USR  responsible 
officer,  was  brought  into  the  meeting  to  discuss  the  USR  process  and  how  the  process 
could  be  simplified  through  the  use  of  an  Intranet.  MAJ  Gamer  mentioned  that  it  would 
be  nice  to  have  a  dynamic  copy  of  the  USR  data  that  could  be  manipulated  at  each 
echelon  level.  MAJ  Gamer  provided  the  team  with  an  electronic  copy  of  the  new  AR 
220-1,  the  regulation  covering  the  USR.  MAJ  Gamer  also  provided  hard  copy  templates 
of  the  USR  report. 
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MAJ  Bruce  Shrewsbeny,  representing  the  G-1,  works  with  Russ  Gamer,  playing 
a  major  role  in  the  USR  process.  MAJ  Shrewsbeny  draws  personnel  information  from  the 
SIDPERS  database  and  consolidates  battalion  size  and  separate  company  personnel 
information.  MAJ  Shrewsbeny  puts  together  the  division's  master  report,  which  shows 
the  results  and  rank  orders  the  23  battalions  and  1 6  separate  compames  in  9  personnel 
readiness  categories.  MAJ  Shrewsbeny  gave  us  an  electronic  copy  of  his  most  recent 
master  report  to  publish  and  include  in  the  prototype.  MAJ  Shrewsbeny  brought  up  some 
ideas  in  reference  to  G-4  related  applications  and  thought  that  it  would  be  nice  to 
integrate  some  of  the  G-4  related  processes  (i.e.,  lateral  transfers  of  equipment,  etc.).  We 
told  MAJ  Shrewsbeny  that  we  had  stayed  away  from  anything  G-4  related  because  the 
Logistics  Automation  System  Support  Office  (LASSO),  which  is  an  office  of  four 
automators,  is  currently  working  to  integrate  their  automated  system  into  this  Intranet 
environment.  In  later  discussions  with  the  G-4,  it  was  determined  that  it  would  be 
beneficial  to  incorporate  some  G-4  related  material  apart  from  the  development  being 
done  by  the  LASSO. 

Three  other  ideas  came  out  of  our  discussions  with  MAJ  Gamer  and  MAJ 
Shrewsbeny.  One  was  the  idea  of  a  suspense  page  imder  each  G  section.  This  woxild 
allow  the  G  sections  to  post  ongoing  suspenses  for  the  division.  Another  idea  was  to  have 
a  page  imder  each  G  section  that  would  indicate  the  submission  frequency  of  all  required 
reports.  The  third  idea  was  to  have  a  telephone  book  section  under  each  entity  section. 

All  three  are  easy  to  implement  and  will  be  included  in  the  developing  prototype.  LTC 
Barham  mentioned  that  his  battalion  is  currently  working  on  a  phone  book  for  the 
division.  We  will  look  to  LTC  Barham  to  populate  the  phone  book  portions  of  the 
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prototype. 

We  gave  our  presentation  to  MAJ  Dimunyatz,  SFC  Oehmen,  and  SFC  Smith  from 
the  G-2  section.  They  mentioned  that  their  primary  battlefield  information  systems 
include  the  All  Sources  Analysis  System  (A  SA  S)  Warrior  and  MSCIMP  Beta.  We  later 
received  a  demo  from  them  on  their  ASAS  Warrior  system.  We  told  them  that  the 
Intranet  would  be  a  system  apart  from  their  battlefield  information  systems.  Some  ideas 
for  the  use  of  the  Intranet  system  include  a  page  for  routine  security  messages,  a  page  for 
a  G-2  newsletter,  a  page  for  Intelligence  Summaries  (INTSUMs),  and  a  page  for  weekly 
threat  updates. 

MAJ  Dimunyatz  said  that  he  is  often  asked  how  many  Intel  soldiers  there  are  and 
where  they  are  located  throughout  the  division.  With  a  divisional  relational  database, 

MAJ  Dimunyatz  could  query  this  information  (i.e.,  MOS=96B)  and  get  a  return  listing  of 
all  his  Intel  soldiers  in  the  division  and  where  they  are  located.  All  this  is  possible  in  the 
proposed  personnel  database. 

We  met  with  MAJ  Jose  Coito,  S-3  240th  Signal  Battalion  over  lunch.  From  the 
team's  perspective,  one  of  the  most  critical  pieces  to  the  division's  new  Intranet  will  be 
the  development,  dissemination,  and  implementation  of  policy  for  the  new  system.  MAJ 
Coito  said  that  as  the  new  system's  proponent  for  the  Division,  the  240th  would  look  into 
the  policy  aspect  of  the  new  system.  The  thesis  team  is  also  looking  into  developing  draft 
policy  for  the  new  system,  especially  as  relates  to  content  context.  MAJ  Coito  reiterated 
that  his  battalion  was  working  on  developing  the  Division's  phone  book  which,  when  put 
together,  could  be  ported  to  the  prototype. 

We  met  with  representatives  MAJ  Dennis  Davis  and  SFC  Fuller  from  the  G-4 
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section  in  the  afternoon.  We  told  them  how  we  had  not  done  any  work  to  date  with  G-4 
related  information  due  to  the  LASSO  section  working  on  porting  logistics  related 
information  systems  over  to  the  Intranet. 

MAJ  Davis  said  that  he  could  break  his  shop  into  4  entity  areas:  supply  (X 
classes),  transportation,  maintenance,  and,  services.  Information  pages  for  each  of  these 
areas  will  be  established  on  the  prototype,  along  with  a  link  to  the  LASSO's  work.  SFC 
Fuller  provided  the  team  with  several  service  request  forms  to  integrate  into  the 
prototype. 

MAJ  Davis  mentioned  that  having  electronic  mail  in  order  to  transmit  and  receive 
action  items  would  be  very  beneficial.  He  also  said  that  controlling  who  (authorization  to 
a  limited  number  of  users)  could  submit  action  items  and  who  would  be  able  to  track 
(who  submitted  what,  when)  those  actions  through  an  audit  trail  would  be  a  critical 
component. 

Electronic  mail  will  be  another  service  that  will  be  made  available  with  the 
implementation  of  the  new  Intranet  system.  Most  of  MAJ  Davis'  concerns  will  have  to  be 
addressed  in  policy  and  procedural  documentation  and  by  the  introduction  of  e-mail  to 
the  division. 

Our  last  meeting  of  the  day  was  with  CPT  Rebman,  who  is  part  of  a  ten  man  5th 
Army  advisor  group.  He  mentioned  how  the  Intranet  would  be  a  useful  medium  for 
posting  advisor-related  information.  I  told  him  we  would  establish  pages  and  links  for  the 
Army  advisor  group  at  the  Division  level  and  at  each  one  of  the  maneuver  brigade  sites. 

We  met  with  our  sponsor,  LTC  Barham,  briefly  before  departing  the  division 
area.  We  told  him  we  had  gathered  a  lot  of  good  information  and  would  put  together  a 
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trip  report  of  the  day's  events.  In  our  initial  meeting  back  in  December,  LTC  Barham 
identified  three  primary  focus  areas:  readiness,  USR,  and  training  schedules.  The 
readiness  focus  area  and  USR  focus  area  overlap.  With  the  USR  process,  the  team  needs 
to  educate  itself  on  the  process  before  we  can  indicate  how  this  area  will  be  implemented 
in  the  Intranet  environment.  The  production  of  a  static  master  report  is  in  the  “easy  to  do” 
category.  How  to  implement  the  rest  of  the  USR  process  will  take  some  education  and 
work  on  the  part  of  the  development  team.  The  training  schedule  focus  will  be  expanded 
into  an  organization  event  calendar  that  will  include  the  major  events  at  each  echelon 
(i.e..  Division,  Brigade,  Battalion,  etc.).  There  were  a  number  of 

requirements/wants/wishes  that  fell  into  the  "easy  to  do"  category  (i.e.,  phonebook  pages, 
completed  master  report,  digital  images  of  commanders  and  staffs,  etc.).  Even  the  event 
calendars  should  not  be  too  difiScult.  The  three  "long  poles"  in  planning  the  next  steps  for 
development  will  be: 

•  once  the  team  becomes  educated  in  the  USR  process,  determining  how  the 
process  can  be  simplified  through  the  use  of  the  Intranet 

•  the  development  of  a  division-wide  relational  database  that  will  be  the  source 
of  timely  and  accurate  information  for  authorized  users 

•  the  development  of  the  Division's  Intranet  system  policy.  The  system's  policy 
has  got  to  be  an  all  encompassing  document  that  covers  every  operational  and 
procedural  aspect  of  the  system 

This  concludes  trip  report  #2.  At  present,  the  thesis  team  anticipates  two  more 
visits  to  the  division  headquarters  before  we  begin  our  write  up. 


119 


APPENDIX  C.  DESCRIPTION  OF  MAJOR  REQUIREMENTS 


I.  Basic  Intranet  Design  From  A  Divisional  Viewpoint 

In  order  to  bring  the  Division’s  Intranet  to  life,  we  had  to  give  it  structure.  The 

Division’s  Intranet  structure  replicates  the  hierarchical  command  structure  of  the  division 
and  is  the  “skeleton”  on  which  the  rest  of  the  Intranet  resides. 

•  Entities  affected:  All  13,579  soldiers  currently  assigned  to  the  division  will 
be  affected. 

•  Number  of  users:  Potentially  all  13,579  soldiers  in  the  division  will  be  users 

•  Primary  Owner:  The  division  commander  would  ultimately  be  responsible 
for  giving  the  authority  to  implement  the  new  division  Intranet.  His  G-6  staff 
officer  would  oversee  the  strategic  level  planning,  implementation,  and 
execution  of  the  system.  The  day-to-day  operational  duties  (adding, 
modifying,  and  deleting  division  level  content,  overseeing  the  content 
postings  of  subordinate  units,  etc)  would  be  done  by  a  dedicated  webmaster 
(still  to  be  determined). 

•  Frequency  of  use:  continuous 

•  Frequency  of  update:  daily 

•  Mode  of  use  by  entities:  All  23  subordinate  battalions  and  18  separate 
companies/detachments  will  maintain  their  own  portions  of  the  division 
Intranet.  Password  access  to  modify  each  of  the  41  “subwebs”  will  be  given 
to  battalion  and  company/detachments  by  the  division’s  webmaster.  This  will 
require  each  battalion  and  company/detachment  to  have  its  own  responsible 
webmaster. 

•  Types  of  information:  Unclassified  information  of  all  types  is  planned  for  the 
system.  Unclassified  but  sensitive  (i.e.,  social  security  numbers)  and 
classified  (i.e..  Unit  Status  Reporting)  material  vdll  be  considered  in  a  closed 
network  context. 

•  Source  of  information:  The  sources  of  information  run  the  gamut,  from 
policies  at  the  division  level,  through  each  entity  level,  all  the  way  down  to  the 
company/detachment  level.  Reports  at  all  levels  are  targets  for  consideration. 
Database  information  from  the  existing  Standard  Installation/Division 


121 


Personnel  System  (SIDPERS)  wdll  also  be  a  source.  Requests  for 
administrative  action  or  support  are  equally  viable  sources  of  content. 

•  Current  Status:  The  division  is  partly  automated  in  that  it  uses  automated 
software  programs  like  word  processors,  spreadsheets,  and  standalone 
databases  to  assist  in  completing  administrative  tasks.  They  have  just 
completed  the  installation  of  ten  dedicated  1-800  lines  and  have  reached  initial 
operational  capability  (IOC)  as  a  fully  capable  Internet  service  provider  (ISP). 

•  Miscellaneous  information:  The  primary  benefit  this  system  provides  the 
division  with  is  the  capability  to  widely  disseminate  timely  information  over  a 
very  broad  geographic  (5  state)  area. 

•  While  on-site  personnel  were  deep  into  planning  access  to  automated  logistics 

•  support  via  the  proposed  Intranet,  no  overall  design  incorporating  access  and 
potential  content  for  the  division  staff  and  subordinate  commands  were  being 
addressed. 


II.  An  interactive  administrative/personnel  database 

The  division’s  current  system  of  tracking  personnel  information  is  called  the 
Standard  Installation/  Division  Personnel  System  also  known  as  SIDPERS.  The 
California  National  Guard  runs  its  own  variant  of  the  SIDPERS  system  that  was 
developed  for  the  active  component. 

A  California  National  Guard  recruiter  enters  a  soldier’s  personnel  information 
into  the  system  upon  his/her  entry  into  the  guard.  Subsequent  entries  or  changes  to  the 
individual’s  personnel  data  are  done  through  a  very  antiquated  process  of  mailing  the 
source  dociunents  (promotion  orders,  copy  of  marriage  certificates,  etc.)  to  the  Office  of 
The  Adjutant  General  (OTAG)  in  Sacramento,  CA.  Division  personnel  we  spoke  with 
who  work  with  the  SIDPERS  system  say  that  the  system  is  never  updated  in  a  timely 
manner  and  continuously  reflects  inaccurate  data.  Another  drawback  of  the  system  is  that 
it  has  a  very  limited  querying  capability. 
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LTC  Barham  mentioned  that  the  need  exists  to  maintain  a  personnel  database  that 
could  reflect  timely  and  accurate  information.  The  Office  of  The  Adjutant  General 
(OTAG)  is  currently  conducting  a  test  case  with  one  of  the  division’s  battalions.  The  test 
gives  the  battalion  the  ability  to  directly  input  and  change  information  in  the  SIDPERS 
system.  Beginning  in  October  of  1997,  implementation  of  this  capability  will  begin  at  all 
the  battalions  in  the  division.  This  initiative  will  certainly  improve  the  accuracy  and 
timeliness  of  the  information.  The  query  limitation,  unfortunately,  will  still  be  present. 
We  have  put  together  a  dynamic  web-based  prototype  which  illustrates  for  the  division 
the  power  and  usefulness  of  a  queryable  database.  If  the  division  were  to  choose  to  refine 
the  prototype  so  it  is  more  robust,  it  should  be  done  in  a  manner  in  which  the  information 
from  the  SIDPERS  database  could  be  imported  directly  into  the  division’s  personnel 
database,  and  updated  periodically. 

•  Entities  affected:  Hundreds  of  command  and  staff  personnel  would  be 
affected  with  the  increased  capability  to  query  any  personnel  related  fields. 
The  improved  capability  woiild  bring  to  bear  more  informed  and  timelier 
decisions. 

•  Number  of  users:  Hundreds  of  S-1  personnel  would  be  the  primary  users, 
but  others  could  also  use  it  if  provided  access. 

•  Primary  Owner:  The  division’s  G-1  would  be  the  primary  owner  of  the 
system. 

•  Frequency  of  use:  continuous  use  on  a  daily  basis 

•  Frequency  of  update:  daily 

•  Mode  of  use  by  entities:  Update  capability  will  have  to  be  limited  to  a  select 
few  to  insure  integrity  of  the  database.  Daily  backups  will  also  be  a  critical 
part  of  the  system’s  operation. 


123 


•  Type  of  information:  In  the  closed  Intranet  scenario,  the  use  of  sensitive  but 
unclassified  traffic  (i.e.,  use  of  SSNs)  will  be  prevalent.  Personnel  data  will 
not  exceed  the  sensitive  but  unclassified  security  level. 

•  Source  of  information:  Ideally,  the  division  wants  to  replicate  the  data  that  is 
tracked  in  the  SIDPERS  database.  The  major  limitation  with  SIDPERS  is  its 
limited  query  capability.  The  hope  is  that  we  will  be  able  to  import  records 
from  the  SIDPERS  database  directly  into  a  web  accessible  Access  database. 

•  Current  Status:  SIDPERS  is  the  standard  and  will  continue  to  be  the 
standard  until  an  Army  wide  system  replaces  it.  Moving  input/update 
authority  to  the  battalion  level  will,  without  a  doubt,  improve  the  timeliness 
and  accuracy  of  the  data  reflected.  The  query  limitations  are  real.  The  ability 
to  retrieve  traceable  information  beyond  the  query  capability  of  the  SIDPERS 
system  is  all  done  manually. 

•  Miscellaneous  information:  The  ability  to  import  SIDPERS  records  into  a 
division-managed  database  needs  to  be  explored.  A  web-based,  division 
managed  database  will  provide  the  command  with  timely  and  queryable 
persoimel  information. 

in.  Readiness  Reporting 

From  a  requirements  perspective,  our  customer  wanted  us  to  study  how  we  could 
simplify  the  readiness  reporting  process.  In  accordance  with  Army  Regulation  (AR)  220- 
1,  Unit  Status  Reporting,  each  battalion  (23  in  the  division)  and  separate  company  (18  in 
the  division)  must  complete  this  lengthy  report.  With  worksheets,  the  report  (DA  FORM 
271 5-R)  is  thirty-one  pages  long.  The  report  is  classified  confidential  when  filled  in. 
Enclosure  6  depicts  the  current  process  in  DFD  format. 

In  accordance  with  AR  220-1,  all  Army  National  Guard  and  Army  Reserve  Units 
must  submit  a  completed  Unit  Status  Report  every  quarter.  According  to  one  battalion 
commander,  organizations  spend  about  a  month  preparing  and  gathering  the  information 
they  need  in  order  to  prepare  the  report.  Once  completed  at  the  battalion  (23)  and 
separate  company  level  (18),  a  representative  from  each  of  these  entities  travels  with  the 


completed  report  to  the  division  headquarters  in  Los  Alamitos,  CA.  Once  there,  the 
reports  are  reviewed  by  the  division’s  USR  responsible  officer  for  completeness.  A 
representative  from  the  OTAG  (the  40*''  division’s  higher  headquarters)  in  Sacramento 
travels  to  the  USR  quarterly  tum-in  and  collects  the  data  from  all  the  submitted  reports. 
This  representative  currently  uses  a  software  program  to  enter  and  store  the  collected 
information.  This  data  is  later  sent  to  the  National  Guard  Bureau  in  Washington,  D.C., 
via  electronic  means. 

The  master  report  is  a  personnel  focused  readiness  report  that  is  prepared  by  the 
Division  readiness  office  (DRO).  Information  for  this  report  is  taken  directly  from  the 
SIDPERS  database  by  the  DRO.  Even  though  all  the  information  for  the  master  report  is 
taken  from  the  SIDPERS  database,  commanders  of  the  twenty-three  battalions  and 
eighteen  separate  companies  are  required  to  send  master  report  information  up  through 
their  command  channels.  The  battalions  and  compames  have  different  methods  for 
acquiring  this  information  from  their  subordinate  entities  (i.e.,  companies  and  platoons). 
LTC  Rod  Barham  uses  a  Microsoft  Excel  spreadsheet  that  he  sends  to  his  subordinate 
commanders  as  an  attached  Multipurpose  Internet  Mail  Extension  (MIME)  file  to  an 
ordinary  e-mail  message.  Upon  completing  their  portion  of  the  spreadsheet,  they  e-mail 
it  to  LTC  Barham,  who  in-tum  submits  the  consolidated  information  to  his  higher  level 
commander.  LTC  Barham’s  model  can  be  adjusted  for  use  at  any  command.  The 
division  uses  a  Master  Report,  which  can  just  as  easily  be  adapted  for  use  by  other 
commands. 

•  Entities  affected:  Literally  himdreds  of  people  would  be  impacted  by  the 
introduction  of  a  web-based  Unit  Status  Reporting  system.  Travel  for  the  forty 
plus  personnel  who  travel  to  Los  Alamitos  every  quarter  could  be  eliminated 
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resulting  in  a  significant  cost  saving  to  the  division.  Working  copies  of  the 
report  could  be  passed  back  and  forth  electronically  via  electronic  mail  until 
the  division  readiness  office  was  satisfied  with  subordinate  entities  final 
products. 

•  Number  of  users:  Every  person  in  the  division  directly  involved  in  division 
readiness  reporting  would  be  involved.  Estimate  of  100  personnel. 

•  Primary  Owner:  The  Division  readiness  office 

•  Frequency  of  use:  daily 

•  Frequency  of  update:  the  draft  USR  reports  could  be  passed  back  and  forth 
as  necessary 

•  Mode  of  use  by  entities:  multiple  update 

•  Type  of  information:  The  USR  is  classified  confidential  when  it  is  filled  in. 
The  master  report  is  an  unclassified  document.  LTC  Barham’s  report  is  also 
an  unclassified  document. 

•  Source  of  information:  Army  Regulation  220-1 :  Unit  Status  Reporting  and 
the  division’s  master  report 

•  Current  Status:  Processes  are  explained  in  paragraph  above 

•  Miscellaneous  information:  The  requirement  from  the  division  readiness 
office  is  to  have  a  dynamic  copy  capability  where  a  subordinate  entity  could 
download  a  blank  report,  fill  it  out  and  send  it  back  to  the  DRO  for  review. 
The  DRO  could  then  either  accept  the  report  or  send  it  back  to  the  submitting 
entity  with  comments.  When  a  revised  edition  of  the  report  is  completed  it 
could  again  be  submitted  to  the  DRO  for  a  second  review.  This  would  be  an 
iterative  process  until  the  report  is  finally  accepted  by  the  DRO. 

IV.  Training  Scheduling/Event  Planning 

A  high  priority  requirement  was  to  develop  an  electronic  means  of  disseminating 
scheduled  events.  The  desire  is  to  have  a  divisional  calendar  which  would  depict  all  of 
the  division  level  events  (i.e.,  guard  weekend  events,  major  field  training  exercises, 
ranges,  etc.) 
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•  Entities  affected:  All  1 3,500  members  who  have  a  personal  computer  and  a 
modem  could  check  the  web-based  calendar  for  timely  scheduling  information 

•  Number  of  users;  see  above 

•  Primary  owner:  Either  the  G-1  or  G-3  would  maintain  an  up-to-date 
schedule.  Most  likely  the  G-1.  Persoimel  staffers  at  all  echelons  (i.e.,  brigade 
S-ls  and  battalion  Sis )  will  most  likely  want  to  maintain  their  own  calendars 
at  their  own  level. 

•  Frequency  of  use:  continuous 

•  Frequency  of  update:  as  necessary  when  events  are  added,  changed,  or 
deleted 

•  Mode  of  use  by  entities:  read  only 

•  Type  of  information:  scheduling 

•  Source  of  information:  primary  staff  input 

•  Current  Status:  Division  uses  calendar  creator  plus  a  calendar  application. 
These  calendars  are  manually  distributed  or  sent  via  fax 

•  Miscellaneous  information:  In  regards  to  policy,  someone  will  have  to  make 
the  decision  who  will  maintain  the  division’s  calendar.  Typically  the  G-3  has 
most  of  the  input  (range  schedules,  field  exercises,  etc.)  but  the  G-1  is  the 
commander’s  administrative  arm. 

During  requirements  gathering,  we  interviewed  each  of  the  four  primary  staff 
elements  (G-1  through  G-4).  During  this  process  we  gathered  some  requirements  that 
were  not  necessarily  a  priority  but  fell  into  the  “nice  to  have”  category.  We  gave  most  of 
them  consideration  if  they  could  be  done  very  quickly  without  too  much  difficulty.  The 
following  paragraphs  speak  to  some  of  the  “nice  to  have”  we  put  in  the  protot5qje. 
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APPENDIX  D.  GUIDANCE  FOR  THE  MANAGEMENT  OF  ARMY  WEBSITES 


Guidance  for  the  Management  of  Army  Websites 
30  October  1996 

Releaser:  LTG  Otto  J.  Guenther,  DISC4 


1.  References: 

A.  Public  Law  100-235,  Computer  Security  Act  of  1987. 

B.  AR  360-5,  Public  Information  (31  May  1989). 

C.  AR  25-55,  Army  Freedom  of  Information  Act  Program  (10  Jan  1990). 

D.  AR  380-19,  Information  System  Security  (1  Aug  1990). 

E.  AR  380-5,  Department  of  the  Army  Information  Security  Program  (25  Feb  1988). 

F.  AR  340-21,  Army  Privacy  Act  Program  (5  Jul  1985). 

G.  AR  25-1,  The  Amy  Information  Resource  Management  Program  (24  May  1991). 

H.  Memorandum,  Deputy  Secretary  of  Defense,  17  Feb  1995,  Subject:  Clearance 
Procedures  for  Making  Electronic  Information  Available  to  the  Public. 

2.  Purpose:  This  message  provides  initial  guidance  for  the  establishment  and  operation  of 
Army  world  wide  websites  ("websites").  A  final  policy  is  being  coordinated. 

3.  This  guidance  applies  to  all  Army  organizations  that  maintain  publicly  accessible, 
non-restricted  websites. 

4.  The  world  wide  web  (WWW)  is  an  efficient  and  effective  means  for  the  U.S.  Army  to 
share  information.  Army  websites  should  focus  on  providing  value-added  information 
services  and  products  to  the  organization's  users,  customers,  the  Army,  and  the  public 
through  the  sharing  of  accurate,  relevant  information.  Army  Websites  can  enhance  the 
execution  of  the  Army's  mission  through  information  sharing,  and  save  resources 
currently  expended  on  traditional  means  of  communication.  To  ensure  that  the  Army 
fully  leverages  the  capabilities  of  the  WWW  in  a  manner  that  is  efficient,  focused  on 
saving  resources,  and  moving  toward  a  digital  environment,  the  following  guidelines  are 
provided. 

5.  The  organization's  leadership  should  evaluate  the  website's  ability  to  provide  value- 
added  service,  enhance  the  execution  of  the  organization's  missions  and  functions,  or 
realize  efficiencies  when  determining  whether  their  organization,  or  subordinate 
organization,  should  develop  or  continue  to  maintain  websites. 

6.  The  organization's  leadership  is  ultimately  responsible  for  the  content  of  the 
organizations  website  and  compliance  with  Army  policy.  The  organization's  leadership 
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will  have  knowledge  of  the  websites  operated  by  their  command  and  subordinate 
commands,  and  the  information  provided  to  the  public  through  these  websites. 

7.  Army  websites  will  provide  the  following  information  or  hyperlinks  to  the  following 
information  on  their  homepage:  (a)  organization  missions  and  functions;  (b) 
organizational  structure,  listing  or  hyperlinking  to  parent  and  subordinate  command  or 
organization  websites  (organizational  charts  containing  individuals'  names  and  other 
personal  information  should  not  be  uploaded  unless  privacy  and  security  concerns  have 
been  addressed;  posting  such  information  for  members  of  deployable  units  and  others  in 
sensitive  positions  could  make  them  potential  targets  of  hostile  organizations  or 
individuals);  (c)  electronic  mail  address,  phone  number,  or  mail  address  of  point  of 
contact  responsible  for  the  website  content;  (d)  a  hyperlink  to  the  U.S.  Army  homepage 
(http://www.army.mil). 

8.  No  classified,  unclassified  but  sensitive,  information  that  cannot  be  disclosed  under 
the  Privacy  Act,  For  Official  Use  Only  (FOUO),  or  Freedom  of  Information  Act  (FOIA)- 
exempt  information  (such  as  draft  policies  and  regulations,  or  pre-decisional  mformation) 
will  be  made  available  to  the  public  through  WWW.  Each  organization  will  institute  a 
review  process  to  ensure  that  information  provided  on  their  website  is  current,  timely, 
and  cleared  for  public  release. 

9.  To  ensure  that  a  user  entering  any  Army  website  can  reach  a  central  source  for 
accessing  all  other  Army  websites,  every  organization  that  maintains  a  website  must:  (a) 
register  their  homepage  with  the  U.S.  Ajmy  homepage  webmaster  through  the  online 
registration  form  foxmd  on  the  Army  homepage;  (b)  provide  a  hyperlink  to  the  U.S.  Army 
homepage  on  their  homepage. 

10.  Personal  use  of  government  resources  generally  is  improper.  Hyperlinks  on  official 
Army  websites  to  personal  homepages  or  websites  are  prohibited. 

1 1 .  Commercial  advertising  on  official  U.S.  Army  websites  is  prohibited.  Corporate  or 
product  logos  and  trade  marks  are  considered  commercial  advertisements,  and  may  not 
be  served  fi'om  official  U.S.  Army  websites. 

12.  Website/document  points  of  contact  ("webmaster")  will:  (a)  ensure  that  information 
published  on  their  website  is  accurate,  timely,  represents  the  official  Army  position,  and 
is  properly  cleared  for  public  dissemination;  (b)  ensure  appropriate  security  and  access 
controls  are  in  place,  commensurate  with  the  perceived  threats,  and  to  ensxore  that 
information  which  is  classified,  unclassified  but  sensitive,  information  that  cannot  be 
disclosed  under  the  Privacy  Act,  For  Official  Use  Only  (FOUO),  or  Freedom  of 
Information  Act  (FOIA)-exempt  information  (such  as  draft  policies  and  regulations,  or 
pre-decisional  information)  is  not  made  available  to  unauthorized  individuals  or 
organizations;  (c)  provide  the  highest  possible  level  of  assurance  that  information  made 
available  to  or  received  from  the  public  does  not  contain  malicious  software  code  such  as 
viruses,  trojan  horses,  logic  bombs,  bacteria  and  worms,  or  if  it  does,  to  sufficiently 
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notify  the  user  before  the  download  of  such  information  begins;  (d)  respond  to  customer 
or  user  email  and  direct  queries  or  requests  for  information  to  the  responsible  party  within 
the  organization;  (e)  ensure  that  the  organization's  website  provides  point  of  contact 
information. 

13.  Point  of  contact:  Mr.  Christopher  Unger,  webmaster@hqda.army.mil,  commercial 
(703)  275-9500,  DSN  235-9500. 

14.  One  Voice  for  the  Army! 


<Picture>to  u.s.  army  homepage 
<Picture>questions  for  webmaster@hqda.army.mil 
<Picture>security  &  privacy  notice 
<Picture>last  update:  19970115 
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